search

keyboardio / attiny_i2c_bootloader

An I2C bootloader for ATTiny devices based on AVR112.
16 stars 6 forks source link

WDT reset loop: should clear WDRF immediately #8

Closed tlyu closed 2 years ago

tlyu commented 2 years ago

The Model 100 keyscanner could likely enter a WDT reset loop if the watchdog timer issues a reset. This probably won't happen under normal usage, though. It's most likely if the bootloader enters command mode and then leaves via a watchdog reset. (For example, running the bootloader flashing sketch for the ATtinys, or pressing the bootloader trigger keys during reset, then timing out.)

This is a somewhat non-obvious consequence of facts documented in the datasheet, but never explicitly stated. If a watchdog reset occurs, all I/O registers are reset to their default values, forcing the watchdog timer to its smallest interval (approx. 15ms). Additionally, watchdog configuration updates will fail while WDRF is set, because the hardware won't clear WDE unless WDRF is cleared first.

The result is that when starting the application after a watchdog reset, the watchdog timer remains enabled at 15ms, causing endless resets in application code every 15ms. The wdt_enable(WDTO_8S) is ineffective, because the Model 100 configuration doesn't touch MCUSR. On the Model 01, with my in-progress unified bootloader trigger code, this causes LED flickering and spurious key reports (probably due to resets in the middle of application code writing a key report to the ATmega). My unified bootloader trigger patch will fix this.

As an additional precaution, the keyscanner initialization code could probably also explicitly clear MCUSR and disable the watchdog timer.

obra commented 2 years ago

Nice catch! And yeah, clearing MCUSR and disabling the watchdog timer ought to be one of the first things the keyscanner code does.

On Tue, May 24, 2022 at 7:01 AM Taylor Yu @.***> wrote:

The Model 100 keyscanner could likely enter a WDT reset loop if the watchdog timer issues a reset. This probably won't happen under normal usage, though. It's most likely if the bootloader enters command mode and then leaves via a watchdog reset. (For example, running the bootloader flashing sketch for the ATtinys, or pressing the bootloader trigger keys during reset, then timing out.)

This is a somewhat non-obvious consequence of facts documented in the datasheet, but never explicitly stated. If a watchdog reset occurs, all I/O registers are reset to their default values, forcing the watchdog timer to its smallest interval (approx. 15ms). Additionally, watchdog configuration updates will fail while WDRF is set, because the hardware won't clear WDE unless WDRF is cleared first.

The result is that when starting the application after a watchdog reset, the watchdog timer remains enabled at 15ms, causing endless resets in application code every 15ms. The wdt_enable(WDTO_8S) is ineffective, because the Model 100 configuration doesn't touch MCUSR. On the Model 01, with my in-progress unified bootloader trigger code, this causes LED flickering and spurious key reports (probably due to resets in the middle of application code writing a key report to the ATmega). My unified bootloader trigger patch will fix this.

As an additional precaution, the keyscanner initialization code could probably also explicitly clear MCUSR and disable the watchdog timer.

— Reply to this email directly, view it on GitHub https://github.com/keyboardio/attiny_i2c_bootloader/issues/8, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALC2AKC5PPYTCKNWSKV53VLTOLZANCNFSM5WZV2J2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>