kbosak 
Hi, I am trying to discover reset reason in atmega 128, the project is already quite large,
playing it from all sides, however
int main()
{
const uint8_t reset_source=MCUCSR;
MCUCSR=0;
when I print reset_source it is always null.
what the?
evil includes?
#include#include #include #include #include #include #include #include #include #include #include #include
I swear it worked for me at least on 2560 as few months ago...
Since you've declared it const it's giving you a cached value instead of the current value?
abcminiuser 
The compiler resets it as part of its initialization routine. You need to fetch the routine before the C startup has a chance to run. To do that, you need to define a routine with a special attribute that will cause the compiler to fetch the value beforehand:
void FetchMCUCSR(void) __attribute__((section(".init3")));
void FetchMCUCSR(void)
{
MCUCSR_Cached = MCUCSR;
}
Note that because this routine is running before the normal startup, you cannot do all the regular things you would normally do in a C routine (such as read in global variables and assume they have a default state). Your init routine should be as small as possible, just caching the MCUCSR value into a global which you can then process as part of your normal main().
- Dean :twisted:
Dean,
Are you sure about the compiler resetting MCUCSR? Are we talking about AVR GCC? What version of AVR GCC?
Eugene
kbosak AvrGcc 2009-03-13 something and the same for the newest 2010-01-10.
Yes I remember it could have been something around .noinit and similars.
Thanks, will try.
curtvm Remove the 'const', then see what happens. Otherwise looks fine. The default startup code does not touch the reset flags.
See wdt.h for when you want to make sure the wdrf is cleared early in the startup process. The mega128 does not have the enhanced watchdog, so it would not be needed in this case.
You don't want a 'non-naked' function in startup code as shown above (you don't want a return). (Dean has too much usb info inside his brain, and its pushing out the 'simpler' stuff).
clawson 
Are you sure about the compiler resetting MCUCSR? Are we talking about AVR GCC? What version of AVR GCC?
abcminiuser Ooops, I think curtvm is right, too much USB junk is pushing the rest of the important stuff out of my brain. I should add a disclaimer onto my signature...
- Dean :twisted:
An elderly ichthyology professor was famous for never knowing his students' names. When asked by a new colleague why he didn't get to know them, he replied "Learn a student, forget a fish."
Mike B 
For WinAVR look in the documentation for ISR (BADISR_vect). If an enabled AVR interrupt is triggered (for the selected AVR chip interrupt table size only) that has no corresponding vector code, it will restart the program. The BADISR_vect is an optional debug breakpoint to catch any interrupts that shouldn't be enabled. Did you remember to remove or change any interrupt vector names just for the 2560 that will not work with the 128 (see the WinAVR documentation for the correct interrupt vector names)?
theusch 
This is the second recent thread with the reset cause "always 0". While programs can certainly run amok, any system should be reporting power-on, and will also report an external reset after an ISP session.
If you don't get those, then examine the reporting system.