OTA - Brick prevention - Buttonless DFU

RE: OTA - Brick prevention - Buttonless DFU

Sigurd — Tue, 18 May 2021 11:33:59 GMT

[quote user="mrono"]How to enter the bootloader in that case?[/quote]

This would be covered by suggestion #2, i.e. when app_error_handler is called. Note that when the device resets, it will boot the bootloader, and the bootloader will decide if it should enter DFU mode, or start/jump to the application.

RE: OTA - Brick prevention - Buttonless DFU

mrono — Tue, 18 May 2021 10:24:16 GMT

Watchdog will generally save you from a stuck application. As Sigurd said, you can configure the bootloader to stay in bootloader mode after a watchdog reset.

Note that your last resort case can also be handled without modifying the bootloader: You can configure the bootloader to also stay in BL-mode if a button is pressed during boot. So add to your user instructions to keep the button pressed when connecting the charging cable.

A trickier case is if your application is faulty in such a way that it can't enter DFU, but isn't completely stuck either. How to enter the bootloader in that case?

RE: OTA - Brick prevention - Buttonless DFU

Sigurd — Tue, 18 May 2021 09:25:12 GMT

Hi,

If you are afraid of your application bricking the device, then here are some suggestions on how to deal with this:

1) Always go into DFU mode after a watchdog-reset. Standard DFU timeout before the bootloader will start the app again is 2 min (NRF_BL_DFU_INACTIVITY_TIMEOUT_MS).
2) For hard-faults and app-errors, you could in the error-handler enter DFU mode by setting the GPREGRET registers and call nvic_systemreset, or loop until the watchdog times out.

[quote user=""]We at some point managed to use TWI wrong which led to an reboot loop. We are not able to reproduce this. But how to deal with such a problem?[/quote]

This link might be useful: https://www.i2c-bus.org/i2c-primer/analysing-obscure-problems/blocked-bus/