Hi All,

I’ve been working on OpenOCD to flash Nordic nRF52 targets (through a
FTDI device).

The flash hex file contains both the S132 BLE SoftDevice and our own
BLE application (i,e. non consecutive pages to flash).
For some reason, flashing this file:
  - fails to flash the N+1 time (algorithm timeout)
  - flashes w/o issue on the N time

After some investigation I think I found the culprit: the application
enables the nRF52 watchdog which exhibits a (boring :-)) limitation:
it cannot be disabled w/o a HW reset or power cycle. A SW reset cannot
help, and the watchdog cannot be reconfigured once it has been kicked
off.
The watchdog is configured so that it does not trigger while the
target is being debugged.

The issue comes from the interaction between the way OpenOCD
-cleverly- handles the flash sequence through the nRF52 NVM
controller, and the watchdog behaviour. OpenOCD uploads the helper
algorithm and runs it. Whenever it runs the algorithm, the target
leaves the debug mode to run in regular/thread mode (until the
algorithm breakpoint instruction is reached). This execution mode
unfortunately resumes the watchdog regular behaviour.

This means that if the flashing of a continuous segment lasts longer
that the watchdog predefined timeout, the watchdog kicks in. The
target reboots without OpenOCD can detect it (I guess). As the flash
was being reflashed by the time of the forced reboot, the CPU executes
some invalid code from the flash, enters a HardFault issue. The
exception vector being usually already flashed, the CPU jumps to the
HardFault handler which is not yet flashed (at least on my setup as it
is located near the end of the application).

The next time a flash sequence is attempted, as the target has
found/executed no valid code, the watchdog has not been enabled, so
the flash sequence succeeds and the target may restart - enabling the
watchdog, paving the way for the next flashing failure.

I ended up with a modified flash algorithm for the nRF52, which feeds
the watchdog every time the circular buffer loops over, it the
watchdog is already enabled when the flash sequence starts.

I wonder if there would be a better way - as this requires patching
OpenOCD nrf5.c file - or using the deadly slow word-by-word flashing
from OpenOCD. Is this kind of issue already handled with other
targets, by which mean(s)?

BTW, is there a way to specify an external binary blob as an
alternative algorithm?

Thanks,
Manu.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to