Closed jamesadevine closed 2 years ago
Thoughts @mmoskal ?
Other than not using the reset line a gpio, I think we need a way to bail out of the RESET_AS_GPIO configuration. It's super risky.
I don't understand the comment about bailing out though.
As for the failure while flashing, the init code runs in bootloader, so I think it should be enough to wait a second or two after flashing bootloader. Once the app starts running, it should not need to re-write the OPTR, as it would be already in the right condition. BTW, we also flash the serial number in OTP on first bootloader run - this could be another potential failure mode.
As for the failure while flashing, the init code runs in bootloader, so I think it should be enough to wait a second or two after flashing bootloader. Once the app starts running, it should not need to re-write the OPTR, as it would be already in the right condition. BTW, we also flash the serial number in OTP on first bootloader run - this could be another potential failure mode.
Then I'm stumped as to what part of the flash-loop process has the chance to brick devices? It sounds like we've been writing to OPTR without any issues so far.
The most obvious conclusion is that I've made a mistake (likely :smile:). Anything jump out at you?
We were writing OTP flash, not flash option registers. I think the second requires a reboot.
There is a temporal relationship with flash-loop and the microcontroller which results in bricked MCUs. I think it is because power is interrupted or the microcontroller is reset when writing to OPTR. The frequency of bricking has increased because we have changed from a logical and with OPTR_MODE to an equality check for OPTR_MODE1 (0x1). The default value is OPTR_MODE_LEGACY (0x3), causing OPTR writes now on every flash...
A safer process would be to remain in OPTR_LEGACY, as this is compatible with OPTR_MODE1 behaviour.