Cannot boot after flashing about toboot HOT 4 OPEN

Are you seeing expected behavior?

Toboot entry is forced after updating: https://github.com/im-tomu/tomu-bootloader/blob/master/booster/main.c#L74

The boot_count value out o be 0, which is why the BOOT_FAILED_TOO_MANY_TIMES code is surprising. What is the order of operations that you're doing?

from toboot.

Sorry, I wasn't clear. I meant the situation when reflashing the bootloader itself using an external programmer.

What I'm doing is that I have both the bootloader and an application already in flash, and then I use OpenOCD and J-Link to flash a new version of the bootloader through the SWD pins, without touching the application. After I reset run in OpenOCD, I expect the bootloader to run and boot the application.

However, the process of reflashing the bootloader through SWD seems to scramble some of the RAM, at least the boot token. I expect the RAM is used as a buffer during flashing, or something. So what happens is that the bootloader looks at the reset cause, and sees that it is not PORST, and therefore expects the boot token to be valid, even though it contains some random fluff after the flashing. (I don't have the exact memory values available right now.)

Everything works fine after power-toggling the device, so it's just an inconvenience for toboot developers.

from toboot.

Since it's generally a 32-bit machine, what if we only consider the boot_count to be valid if board_model is correctly set? Most processes (such as OpenOCD) will overwrite entire words, so those would invalidate the boot_count value as well.

from toboot.

I feel using an eight-bit number for this purpose is a bit hazardous. And I doubt anything would scramble the second word in RAM while leaving the first one (magic number) intact. So I still think just having a special value in the magic field should be enough.

from toboot.