Watch dog disable in bootloader

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

Hello,
I am writing a bootloader for Mega328.
I have read many threads and all suggesting to disable WDT and clear MCUSR register immediately. Can someone explain why?
I thought WDT will be disabled by default ? since I start my boot loader only from reset so everything should be defaulted.

This topic has a solution.
Last Edited: Wed. Nov 8, 2017 - 03:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the WDTON is programmed, the WDT will be active on reset...

The WDE bit is NOT cleared on reset...

 

David (aka frog_jr)

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

A virgin 328 does not have watchdog active so if you do nothing to enable it you can ignore it completely.

 

HOWEVER the way some (good) bootloaders work is that when they finally decide that bootloading is over and they want to run the app code they could just do a "JMP 0" but then the app will be entered with "the mess left behind" by the bootloader still active. So if you want to give the app code a "clean machine" with (almost) everything set to default the last act of the bootloader is to enable the watchdog then sit in a tight loop so it will reset. When that occurs (because of BOOTRST) the reset entry is back at the start of the bootloader but the clever bootloader writer knows that the while every peripheral, interrupt source and everything else is now reset to the power on state the one thing that is different between this entry to the bootloader and "normal" power on reset flag is that in MCUSR it is WDRF and not PORF that is set. So this is telling the bootloader "you just deliberately reset yourself". So the early start up code in the bootloader reads MCUCR, sees WDRF (and then resets it to make sure it's clear for the next reset if one should happen) and now finally does the "JMP 0" to enter the app code safe in the knowledge that the bootloader did its job, the AVR is almost completely reset back to "clean" power on state and the app code can now be entered where the app will find no evidence that it wasn't just a power on reset to 0. (well if it tried hard enough it could read MCUSR and see that for itself).

 

THAT is how WDT is usually involved with bootloaders.

 

Just one thing though, suppose the bootloader wants to use WDT for this purpose but the app itself wants watchdog protection too? In that case the entry code at the start of the bootloader not only has to see WDRF in MCUSR to know it was a watchdog reset but it needs some other way to differentiate between "deliberate reset caused by bootloader itself to reinit the AVR" and "real watchdog reset because app locked up". This can be done because power remains applied at all times so, while the peripherals are rest, the RAM is not (not until later in the bootloader start up) so the bootloader can set a RAM flag to itself on the occasion it is doing the "deliberate reset". OTOH you could just treat all WDRF resets the same and always JMP 0 to the app.