Issuing a reboot on ATmega328p makes the board loop-reboot

[zqad]

Consider this sample program:

#include <stdio.h>
#include <periph/pm.h>

int main(void)
{
	puts("Rebooting!\n");
	pm_reboot();
	return 0;
}

Running it on the board gives this result on my serial console:

Rebooting!



main(): This 
             
main(): This é
              
main(): This 
             
main(): This é

The error is due to the usage of the watchdog as the reboot method, without properly clearing the WDRF bit in MCUSR. This means that the watchdog will be activated with a 250ms timeout on the next reboot.

I have prepared a patch which I will add as a pull request to this issue. Feel free to give feedback on it, in case you find anything noteworthy with it.

Thanks,
/Jonas

[zqad]

The pull request is added as #6837 , the result of which is this serial port output for the same program:

main(): This is RIOT! (Version: 2017.04-devel-638-gdf32c-lisen)
Rebooting!



main(): This is RIOT! (Version: 2017.04-devel-638-gdf32c-lisen)
Rebooting!



main(): This is RIOT! (Version: 2017.04-devel-638-gdf32c-lisen)
Rebooting!

[mali]

Hummm .. I think I've bricked my board while testing the code above.
avrdude fail to flash because board reboot on loop

avrdude -p m328p -c arduino -P /dev/ttyUSB0 -b 57600 -F -D -U flash:w:bin/arduino-duemilanove/default.hex
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
and so on ...

@zqad Any good idea on how to recover from this situation ?

[mali]

Ok, board unbricked !

[zqad]

Ah, good. Could not find anything matching that situation myself.

[mali]

But the bad news is that I've tested with your patch applied and result is the same ... loop-reboot ...

[zqad]

That is bad news. Are you using the same avrdude command as above? I hope that I can get some time in the beginning of next week to try it again myself.

[mali]

@zqad , yes the same avrdude commande, in fact i just do a make BOARD=arduino-duemilanove flash term

[ZetaR60]

The ATmega1284P has this reboot-loop issue as well. Tested on BOARD=mega-xplained

[kYc0o]

Is this issue still valid on current master?

[ZetaR60]

@kYc0o Confirmed just now on mega-xplained.

[mali]

@kYc0o Confirmed on duemilanove, the strange thing is that it works well with uno (these two boards are atmega328p based). And the #9141 don't fix for duemilanove.

[ZetaR60]

@mali Are there fuse setting differences between boards that work and those that don't? The only other things I can think of that's significantly different between the two is the bootloader and UART adapter.

[mali]

@ZetaR60 fuses settings attached, honestly, I don't know how to interpret this ..

uno.txt
duemilanove.txt

[ZetaR60]

Weird. It is reading the fuses as all being set to 0. Maybe retrieving it over USB is unsupported.

I found the default fuse settings for both boards on some website and neither have watchdog always on set.

[kYc0o]

Strangely I don't experience this on current master EDIT: in arduino-uno. Can anyone re-confirm this issue in another platform?

[ZetaR60]

arduino-uno: fixed?
arduino-duemilanove: crashes when executing reboot
mega-xplained: still reboot loops

Not sure what has changed to make Arduino-Uno work now (and Duemilanove crash).

[ZetaR60]

Fixed by #9866. Closing.