MCUSR is cleared in bootloader

[GoogleCodeExporter]

I am running optiboot on an ATmega1284P and everything is working perfectly! 
But I would like to detect when a watchdog timer caused the reset, but due to 
this line: 
https://code.google.com/p/optiboot/source/browse/optiboot/bootloaders/optiboot/o
ptiboot.c#433 it is not possible at the moment, as the MCUSR register is set to 
0 just before the app starts.

What is the reason for doing this? Would it be possible for me just to clear 
everything but the WDRF register with no side effects?

Thanks a lot for all your work!

Original issue reported on code.google.com by laus...@gmail.com on 5 Mar 2014 at 9:44

[GoogleCodeExporter]

Okay. I should properly have read code more properly...
You save the register value: 
https://code.google.com/p/optiboot/source/browse/optiboot/bootloaders/optiboot/o
ptiboot.c#805.

This issue should be closed. I will post some code on how to read it, if I 
figure it out.

Original comment by laus...@gmail.com on 5 Mar 2014 at 10:00

[GoogleCodeExporter]

I finally found this code: 
https://code.google.com/p/optiboot/issues/attachmentText?id=66&aid=660004000&nam
e=resetFlags_appCode.cpp.
Maybe you could add a link to it in the next revision of the code?

Original comment by laus...@gmail.com on 7 Mar 2014 at 5:28

[GoogleCodeExporter]

Hi there,
I tested this code and have some issues (not due to the code but the way 
optiboot start the sketch), let me explain.

First I would like to know on my sketch where I'm coming from. Since MSB of 
MCUSR are not used I decided to use these one on ch var to pass some paramaters 
to my main sktech. Setting bit 7 of ch to indicate a quick start from bootloader
So I changed the line
  if (!(ch & _BV(EXTRF))) appStart(ch);
by
  if (!(ch & _BV(EXTRF))) appStart(ch|0x80);

I my Arduino Sktech I have as you suggested 

uint8_t resetFlags __attribute__ ((section(".noinit")));
void resetFlagsInit(void) __attribute__ ((naked)) __attribute__ ((section 
(".init0")));
void resetFlagsInit(void)
{
  // save the reset flags passed from the bootloader
  __asm__ __volatile__ ("mov %0, r2\n" : "=r" (resetFlags) :);
}

so my global var resetFlags reflect the ch passed to me by bootloader. like 
this I know in my main program that I'm coming from bootloader and that this 
one (bootloader) done nothing else started us quickly if bit 7 = 1 (0x80).

my setup is as follow
void setup() 
{
  // Get reset flags
  resetFlagsInit();

  Serial.begin(115200);
  Serial.print(F("I received from optiboot => "));   
  Serial.println(resetFlags, HEX);
}

Ok, now time to do tests. For now, I've not tested POR or BOR (BOD)I'm focusing 
on my need.

When uploading a sketch the process should be
  1) external reset from DTR
  2) bootloader fire uploading
  3) bootloaded upload sktech, then fire watchdog 
  4) reset occurs (the watchdog)
  5) bootloader start, do not detect external reset pin set bit 7 of ch, start the sketch passing ch to main program

so I should read 0x88 ? is that correct ? this is what I'm reading

Now if I reset with reset pushbutton 
  1) external reset from reset line (same as DTR)
  2) bootloader fire trying uploading
  3) bootloaded found nothing to upload so watchdog timout fire a reset
  4) reset occurs (the watchdog)
  5) bootloader start, do not detect external reset set bit 7 of ch, start the sketch passing ch to main program

so I should read 0x88 ? is that correct ? this is what I'm reading

I'm protecting my sketch with watchdog and for my need, I'm unable to detect if 
watchdog has been fired by my app or bootloader. I'm trying to think a solution 
that can help me to detect (avoiding writing information to eep from 
bootloader) at least
 1) bootloader started quick (done by adaboot mod and 0x80 on ch)
 2) know if we just have been uploaded (new sktech)
 3) know if my application fired the watchdog or if it is the bootloader

If anyone have great magic idea, It will be fine to share ;-)

by the way could we do after uploading a 
exec appStart(ch|0x40) and a 
exec appStart(ch|0x20) if entered bootloader without receiving sketch to upload 
instead of firing the watchdog ? This could give us all information we need ?
ok it will not be a real "reset" init but we could survive to this since 
Arduino Code do his own init ? 

What do you guys think ? possible ?

Thank's for reading this long post

Original comment by ch.hall...@gmail.com on 4 Jun 2014 at 12:47

[GoogleCodeExporter]

I can't even think of a good way to distinguish between the "uploaded a sketch" 
WDT and the "timed out" WDT.  Sometimes these things are handed using RAM or 
registers that otherwise do not have guaranteed contents, but this is generally 
unreliable, and takes more code the more reliable you try to make it (sticking 
a long magic number in RAM is better than a single byte, but takes more code to 
insert and to check.)

Original comment by wes...@gmail.com on 27 Jun 2014 at 6:57

[GoogleCodeExporter]

Original comment by wes...@gmail.com on 28 Jun 2014 at 9:42

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I too would like to see MCUSR preserved and therefore available to the sketch 
after the Optiboot sequence.

Original comment by ita...@googlemail.com on 25 Aug 2014 at 2:59