You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In 7.0+, an application can set MCUSR to 0 and call or jump to the Optiboot Start address, in order to (for example) load new software by user request (used by some over-the-air updates that don't have DTR in there hardware.)
Unfortunately, since Optiboot no longer resets MCUSR (so that an application can detect a watchdog timeout, for example), this will result in the application being started with the watchdog timer enabled, since the second reset used to start the sketch won't detect any reason to turn off the watchdog.
I don't think there's anyway to fix this while preserving the functionality desired by applications that want to actually use the watchdog. Essentially any application that uses either the "application request" feature of Optiboot will also need to handle turning off the watchdog...
The text was updated successfully, but these errors were encountered:
Discussion: #247
In 7.0+, an application can set MCUSR to 0 and call or jump to the Optiboot Start address, in order to (for example) load new software by user request (used by some over-the-air updates that don't have DTR in there hardware.)
Unfortunately, since Optiboot no longer resets MCUSR (so that an application can detect a watchdog timeout, for example), this will result in the application being started with the watchdog timer enabled, since the second reset used to start the sketch won't detect any reason to turn off the watchdog.
I don't think there's anyway to fix this while preserving the functionality desired by applications that want to actually use the watchdog. Essentially any application that uses either the "application request" feature of Optiboot will also need to handle turning off the watchdog...
The text was updated successfully, but these errors were encountered: