ProMini: Reboot loop when using watchdog

[tuxedo0801]

Hi there,

i have the following problem:

I have an arduino sketch which accept some configuration-details over the serial connection. After applying some configuration, a "reboot" is required. On my leonardo and micro boards, this works quite well by using the watchdog to reset the board:

    wdt_enable( WDTO_1S ); 
    while(1) {}

But with an arduino pro mini at 3,3V/8Mhz the board loops in a restart-loop, forever.
It seems that this issue is already known on the net:

https://andreasrohner.at/posts/Electronics/How-to-make-the-Watchdog-Timer-work-on-an-Arduino-Pro-Mini-by-replacing-the-bootloader/

I know that there are othr techniques to "reboot" an arduino, but the WDT seems to be the only real hardware reboot, triggered by software.

Of course I can use the optiboot bootloader to overcome this issue. But this adds some additional complexity and arduino ide tweaking-skills, which I would like to avoid (there are other people using my sketches/libraries which won't be able to tweak the arduino ide properly).

Would it be possible to fix this in arduino ide direclty? For example by switching to optiboot by default or fix the "bug" in the current used bootloader?!

br,
Alex

[tuxedo0801]

I now tried the optiboot bootloader (with Arduino Nano, instead of ProMini, but the AVR is the same...)... Without any success ... Flashing the bootloader was not a problem, but the issue is not gone...

Any hints on this?

[tuxedo0801]

A collegue found of, that if he adds the following

##############################################################
## Optiboot on 32pin (SMT) CPUs (Nano, Pro Micro, etc.)
##############################################################

optiboot32.name=Optiboot on 32-pin cpus (3.3V Pro Mini)
optiboot32.upload.tool=arduino:avrdude
optiboot32.upload.protocol=arduino
optiboot32.bootloader.tool=arduino:avrdude
optiboot32.bootloader.low_fuses=0xF7
optiboot32.bootloader.unlock_bits=0x2F
optiboot32.bootloader.lock_bits=0x0F
optiboot32.build.f_cpu=8000000L
optiboot32.bootloader.low_fuses=0xE2
optiboot32.upload.speed=57600
optiboot32.build.board=AVR_UNO
optiboot32.build.core=arduino:arduino
optiboot32.build.variant=arduino:eightanaloginputs
optiboot32.upload.maximum_size=32256
optiboot32.upload.maximum_data_size=2048
optiboot32.bootloader.high_fuses=0xDE
optiboot32.bootloader.extended_fuses=0x05
optiboot32.bootloader.file=optiboot/optiboot_atmega328.hex
optiboot32.build.mcu=atmega328p

to the boards.txt and chose this new board-type in the IDE, the WDT Problem is gone.

So, just replacing the bootloader.file line with the optiboot variant as suggested in the link from my 1st post, seems not enough.

Could someone with more expertise comment on this issue? Is there a way to fix this for all others too? Or does everyone facing this issue has to modify boards.txt themselves?

[matthijskooijman]

Comparing that with the original nano entry, I suspect that the fuse bits influence this. Comparing these, I've found that the clock selection is different (the nano uses the external crystal, your entry uses the internal oscillator) and the bootloader size is different (nano has 1024 words, your entry 256).

I considered the latter is the reason it doesn't work - the bootloader size defines the start address, so when that is still at 1024, the CPU boots up at the wrong place. Since unused bytes are 0xff which I think are just (effectively) nop instructions, the CPU first has to grind through (1024-256=768) 0xff bytes before reaching the bootloader, which is probably some 1600 cycles or something, or 100us. Since the smallest watchdog timeout is 2ms, optiboot should still be in time to reset MCUSR, so perhaps that's not it. Perhaps you could try modifying the nano entry to use optiboot and use high_fuses=0xDE to just set the bootloader size, to see if that is sufficient?

[tuxedo0801]

That's what I planned to try this evening. I will report back if it works.

If this fixes the problem, the question still is: why does the WDT bring the nano and promini (with default bootloader) etc. in an forever-boot-loop? Can this be fixed in default bootloader?

[matthijskooijman]

The problem is, I think, that the bootloader does not clear the MCUSR register (or specifically the watchdog-related bit in there). This bit is set on a watchdog reset and forces the watchdog enabled. (with a 2ms timeout). The idea is, I think, that an application reconfigures the bootloader on startup, but if it fails to do so, the bootloader is already enabled to prevent a lockup. But this scheme doesn't play well with Arduino's bootloader / sketch separation, so bootloaders should just disable this bit on start, which I think optiboot does but not some of the other bootloaders. It should be fixable, but it's probably better to just switch all boards to optiboot (@cmaglie any thoughts on that?)

[tuxedo0801]

Sounds good.
Of course I can for now switch all to optiboot. But this would be a workaround for a bug (?).
So it would be better to fix the bug.
As there are many avr 328p boards out there, it would take a while ;-) to get new boards with the fixed bootloader.

For now, I will try to create a board manager json URL that provides "a fixed boardconfiguration" to enable the users to easily update/flash the correct configured optiboot bootloader.

[tuxedo0801]

tested a lot with optiboot. On nano and promini.
Result:

Optiboot in principle solves the issue, but there are strange side-effects, for example:

• After burning optiboot with usbtiny, i can flash a sketch via serial only once. Then I have to reburn the bootloader to flash a new sketch.

I returned to default arduino bootloader and try to avoid the WDT completely, until this issue is solved in arduino bootloader for 328p.

+1 for fixing the existing bootloader.

[tuxedo0801]

Had a look at the bootloader-code, found this:

https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168.c#L282

#ifdef WATCHDOG_MODS
    ch = MCUSR;
    MCUSR = 0;

    WDTCSR |= _BV(WDCE) | _BV(WDE);
    WDTCSR = 0;

    // Check if the WDT was used to reset, in which case we dont bootload and skip straight to the code. woot.
    if (! (ch &  _BV(EXTRF))) // if its a not an external reset...
        app_start();  // skip bootloader
#else

So MCUSR actually is cleard, but only if WATCHDOG_MODS is enabled?!

[tuxedo0801]

It is enabled, but not for all AVRs:

https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/bootloaders/atmega/Makefile#L94

[tuxedo0801]

ping

Are there any side-effects if we enable this for the 328p as well?

[tuxedo0801]

push

[tuxedo0801]

push again

We faced the same issue with an ATmega644 ... :-( We try to use the WDT Reset to "reboot" the device via software. But this does not work on 328p and 644. So we use the

asm volatile ("  jmp 0");

workaround, which is actually not really the same.

Would be great if someone could comment on this issue.

[va7ta]

Greetings,

I am the originator of duplicate issue arduino/Arduino#6228. I did not notice this duplication as I encountered the problem prior to having the WDT installed by my app thus I thought it was a different issue. I added WDT code to my app as an after-thought as an attempt to resolve the potential lock-up loop situation.

What I think maybe key to resolving this issue (I apologize in advance if this is just obvious to those in the know) is that in my Nano case a power-off/on cycle reset always restores the program were in contrast neither WDT nor external reset via the reset pin will restore operation. Thus it might be possible to identify the root cause by focusing on the difference between a successful power-on reset and an unsuccessful external pin reset. In any case IMHO the WDT should always be left unconditionally disabled by the boot code until the application setup code specifically initializes it.

[va7ta]

The installation of the optiboot bootloader resolved the WDT lockup issue for my NANO board. I found the information at the following website very helpful:

https://andreasrohner.at/posts/Electronics/How-to-make-the-Watchdog-Timer-work-on-an-Arduino-Pro-Mini-by-replacing-the-bootloader/

I hope those involved with the Arduino IDE development will consider making optiboot the default bootloader for all the 32 pin SMD Atmega328 Arduino boards as is presently done for the UNO.