MCUCSR always null...

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you've declared it const it's giving you a cached value instead of the current value?

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,

Are you sure about the compiler resetting MCUCSR? Are we talking about AVR GCC? What version of AVR GCC?

Eugene

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Are you sure about the compiler resetting MCUCSR? Are we talking about AVR GCC? What version of AVR GCC?

Nope, on this rare occasion I'm afraid Dean is wrong the GCC startup code only (in .init2) puts 0 into R1, sets SP, clears SREG, then (in .init4) copies .data and wipes .bss then (in .init9) CALLs to main(). Nothing more. So need to put MCUCSR access code in .init3 (at which point .data/.bss have NOT been prepared - so it would need to be held in a .noinit variable anyway). There's nothing wrong with the OP's intention of grabbing it at the top of main() - or indeed anywhere if his programs doesn't otherwise touch MCUCSR - the error was simply the use of 'const' on something that isn't constant as has already been mentioned.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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."

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.