Why is all of MCUSR set to 0?

[GoogleCodeExporter]

I don't see why this should be done at all. Evaluating that register does not 
require setting all of it to 0 afterwards. WDRF can be set to 0 individually.

It would be nice to be able to use the information (reset source) later.

Original issue reported on code.google.com by madworm_...@spitzenpfeil.org on 21 Apr 2012 at 8:35

[GoogleCodeExporter]

It's quite simple to buffer MCUSR in the 'startup' code of the main program and 
reset it there. Looking at the increased code size since 1.0, a couple of bytes 
for that don't really matter.

Original comment by madworm_...@spitzenpfeil.org on 21 Apr 2012 at 8:43

[GoogleCodeExporter]

You'd never see EXTRF at sketch level, since that state is used to enter the 
bootloader itself, so it HAS to be cleared (the bootloader would then use WDR 
to start the sketch, leaving WDRF set instead.)
Non-EXTRF resets could go direct to the sketch without resetting MCUSR, I think.
Does that sound reasonable?

Original comment by wes...@gmail.com on 28 Apr 2012 at 5:43

[GoogleCodeExporter]

Incorporating changes from dkinzer patch here: 
ttp://code.google.com/p/arduino/issues/detail?id=794
I don't see a reason for the change to be conditional; GP register contents 
don't have a known value after reset anyway.

Original comment by wes...@gmail.com on 5 Jan 2013 at 5:06

[GoogleCodeExporter]

committed: 
http://code.google.com/p/optiboot/source/detail?r=4c68314d6b15eae1bad09dd4591e63
0f367cd679

Attached is sample code for saving the reset cause in the main C or C++ app.

Original comment by wes...@gmail.com on 5 Jan 2013 at 5:29

• Changed state: Fixed

Attachments:

• resetFlags_appCode.cpp

[GoogleCodeExporter]

Hi guys,
I've done the modification and tested, this is working fine when I compile and 
upload from IDE 1.0.5 from Windows.
Unfortunably when I'm compiling on my Raspberry PI with Arduino-mk, my sketch 
won't start until I remove this patch.
Anyone succeded to got it working when compiling on Linux ?

Original comment by ch.hall...@gmail.com on 11 Jun 2014 at 9:31

[GoogleCodeExporter]

Just compiled 'optiboot-v5.0a' on linux and it seems to work (atmega168). I 
didn't test the MCUSR part though.

Original comment by madworm_...@spitzenpfeil.org on 11 Jun 2014 at 2:09

Attachments:

• optiboot-v5.0.a__atmega168-hex.zip

[GoogleCodeExporter]

Although I must say that this baudcheck.tmp.sh script doesn't seem to run 
properly. Not sure if this is a character encoding issue, but the output has 
"funky" characters in it.

Original comment by madworm_...@spitzenpfeil.org on 11 Jun 2014 at 2:30

[GoogleCodeExporter]

Might be a bug in make? Everytime AVR_FREQ is used things go belly up.

E.g. "make atmega644p" works, but "make atmega644p AVR_FREQ=16000000L" doesn't. 
The weird thing is that F_CPU ends up with a different value each time.

Original comment by madworm_...@spitzenpfeil.org on 11 Jun 2014 at 3:13

[GoogleCodeExporter]

Build log for several runs.

Original comment by madworm_...@spitzenpfeil.org on 11 Jun 2014 at 4:03

Attachments:

• log.txt

[GoogleCodeExporter]

Could you open a new issue, since this one is different and already marked 
"fixed"?
Which linux are you running, and which version of avr-gcc?
Elsewhere it's been reported that "sh" on some newer distributions is not 
compatible with the shell script I generate :-(

Original comment by wes...@gmail.com on 11 Jun 2014 at 7:45

[GoogleCodeExporter]

Done.

Original comment by madworm_...@spitzenpfeil.org on 11 Jun 2014 at 9:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

https://code.google.com/p/optiboot/issues/detail?id=106&sort=-id

Original comment by madworm_...@spitzenpfeil.org on 25 Aug 2014 at 3:01

[GoogleCodeExporter]

Thanks for the quick response madworm, however I think you may not have passed 
the link I was expecting. The link goes to "AVR_FREQ gets messed up --> F_CPU 
set to invalid characters (random?)"

Original comment by ita...@googlemail.com on 27 Aug 2014 at 7:45

[GoogleCodeExporter]

Using the example code and latest optiboot, I am seeing WDRF on poweron, i.e 
plug arduino Nano into USB etc...
I expected not to see WDRF on initial bootup.
 Is the watchdog resetting before my code runs?
Here is a code snippet:
main.c:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>
#include <util/delay.h>

#include "hardware.h"
#include "wd.h"

#include "state-machine.h"
#include "command.h"
#include "log.h"

// Watchdog and reset state.
// NOTE: This code will work with a recent version of 'optiboot' as the 
bootloader:
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) :);
}

int main() {    
    cli();
    init_hardware();
    set_sleep_mode(SLEEP_MODE_IDLE);
    wd_reset();
...
    send_uint16(resetFlags);
...

init_hardware contain:
void init_hardware(void ) {
    wd_reset();
    WD_SET(WD_OFF);
    init_clock();
    init_usart(38400, F_CPU);   //Initialise USART with speed 38400baude
    i2c_init(400000,F_CPU);     //Initilise I^2C with speed 100kHz
    init_io_ports();            //Initialise IO ports
    WD_SET(WD_RST,WDTO_4S);
}

What am I doing wrong please (Absolute n00b to this)

Original comment by jasper.m...@gmail.com on 9 Oct 2014 at 12:20