Hi Emmanuel, I used OpenOCD to flash NuttX firmware image inside nRF52 module and it worked fine.
These are the steps: https://acassis.wordpress.com/2018/04/03/how-to-install-nuttx-on-nordic-nrf52832/ BR, Alan On 6/21/18, Emmanuel Blot <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ 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
