I'm trying to support nRF52833 in Embeetle IDE, but flashing through OpenOCD + GDB doesn't work.

[kristof.mulier]

1. Background info

We're developing a new IDE for microcontrollers (see https://embeetle.com) and would like to support a range of Nordic Semiconductor microcontrollers. We received the nRF52833 board on Embedded World 2020 from Mr. Reidar Martin Svendsen for this purpose.
 

2. Flashing failure

We use the combination OpenOCD and GDB to flash the microcontroller. On the OpenOCD side, I get the following output:

    
    Open On-Chip Debugger 0.10.0+dev-00973-g80f1a92bd (2019-12-02-17:58)
    Licensed under GNU GPL v2
    For bug reports, read
    openocd.org/.../bugs.html
    swd
    Info : J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 21 2020 17:30:48
    Info : Hardware version: 1.00
    Info : VTarget = 3.300 V
    Info : clock speed 1000 kHz
    Info : SWD DPIDR 0x2ba01477
    Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
    Info : Listening on port 3333 for gdb connections
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    Info : Listening on port 6666 for tcl connections
    Info : Listening on port 4444 for telnet connections
    Info : accepting 'gdb' connection on tcp/3333
    Info : nRF52833-xxAA(build code: A0) 512kB Flash, 128kB RAM
    Warn : Flash protection of this nRF device is not supported
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    Error : Cannot erase protected sector at 0x0
    Error : failed erasing sectors 0 to 15
    
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    ** Programming Started **
    Warn : Adding extra erase range, 0x00003810 .. 0x00003fff
    Error : Cannot erase protected sector at 0x0
    Error : failed erasing sectors 0 to 3
    embedded:startup.tcl:460: Error : ** Programming Failed **
    in procedure 'program'
    in procedure 'program_error' called at file "embedded:startup.tcl", line 525
    at file "embedded:startup.tcl", line 460
    shutdown command invoked
    

And on the GDB side, I get this:

    
    (gdb) target remote localhost:3333
    Remote debugging using localhost:3333
    warning: No executable has been specified and target does not support
    determining executable automatically. Try using the "file" command.
    0x00000414 in ?? ()
    
    (gdb) monitor reset halt
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    
    (gdb) monitor flash erase_address 0x00000000 0x10000
    Cannot erase protected sector at 0x0
    failed erasing sectors 0 to 15
    
    (gdb) monitor reset halt
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    
    (gdb) monitor program "C:/Users/Gebruiker/beetle_projects/pca10100/build/myApp.elf"
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    ** Programming Started **
    Adding extra erase range, 0x00003810 .. 0x00003fff
    Cannot erase protected sector at 0x0
    failed erasing sectors 0 to 3
    embedded:startup.tcl:460: Error : ** Programming Failed **
    in procedure 'program'
    in procedure 'program_error' called at file "embedded:startup.tcl", line 525
    at file "embedded:startup.tcl", line 460
    
    (gdb) monitor reset run
    
    (gdb) monitor shutdown
    shutdown command invoked
    
    (gdb) quit
    A debugging session is active.
    Detaching from program: , Remote target
    Remote communication error. Target disconnected.: Success.
    

 

As you can see, OpenOCD cannot erase the protected sector at 0x0. In fact, I don't know if I need to erase that sector before flashing new code. Anyway, even the flashing of the .elf itself fails:

    
    (gdb) monitor program "C:/Users/Gebruiker/beetle_projects/pca10100/build/myApp.elf"
    
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x00000414 msp: 0x20002450
    ** Programming Started **
    Adding extra erase range, 0x00003810 .. 0x00003fff
    Cannot erase protected sector at 0x0
    failed erasing sectors 0 to 3
    embedded:startup.tcl:460: Error: ** Programming Failed **
    in procedure 'program'
    in procedure 'program_error' called at file "embedded:startup.tcl", line 525
    at file "embedded:startup.tcl", line 460
    

I've also tried another approach to flash the microcontroller. I start OpenOCD with the flags -c "gdb_flash_program enable" -c "gdb_breakpoint_override hard" to make sure that GDB has full control. In GDB I issue the commands:

    
    (gdb) file "C:/Users/Gebruiker/beetle_projects/pca10100/build/myApp.elf"
    A program is being debugged already.
    Are you sure you want to change the file? (y or n) [answered Y; input not from terminal]
    Reading symbols from C:/Users/Gebruiker/beetle_projects/pca10100/build/myApp.elf...
    
    (gdb) load
    Loading section .data, size 0x6c lma 0x20000000
    Error erasing flash with vFlashErase packet
    

For these two GDB commands, I get the following output in OpenOCD:

    
    Error : Cannot erase protected sector at 0x0
    Error : failed erasing sectors 0 to 3
    Error : flash_erase returned -4
    Error : nrf52.cpu -- clearing lockup after double fault
    

---

3. Solution

The problem is solved thanks to the OpenOCD community. They fixed the problem in the latest OpenOCD build. (end of March 2020). For a step-by-step guide on how to build OpenOCD from the source code, see:
https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build
or see:
https://xpack.github.io/openocd

I get the following in GDB:

    
    (gdb) target remote localhost:3333
    Remote debugging using localhost:3333
    warning: No executable has been specified and target does not support
    determining executable automatically. Try using the "file" command.
    0x00000414 in ?? ()
    
    (gdb) monitor nrf5 mass_erase
    Flash protection of this nRF device is not supported
    Failed to check chip's write protection
    
    (gdb) monitor flash erase_check 0
    successfully checked erase state
    Bank is erased
    
    (gdb) monitor program "C:/Users/Gebruiker/beetle_projects/pca10056/build/myApp.elf"
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
    ** Programming Started **
    Adding extra erase range, 0x00000bc4 .. 0x00000fff
    ** Programming Finished **
    
    (gdb) monitor reset run
    
    (gdb) monitor shutdown
    shutdown command invoked
    
    (gdb) quit
    A debugging session is active.
    
    Inferior 1 [Remote target] will be detached.
    
    Quit anyway? (y or n) [answered Y; input not from terminal]
    Detaching from program: , Remote target
    Remote communication error. Target disconnected.: Success.
    

Huray! The flashing workes! I've tested on both the PCA10100 (nRF52833) and the PCA10056 (nRF52840) development boards. The blinky projects from the SDK work fine:
nRF5_SDK_16.0.0_98a08e2/examples/peripheral/blinky_freertos/

As you can see, trying to erase the flash memory through giving the nrf5 mass_erase command to OpenOCD results in an error message. This seems to be a bogus error message, because OpenOCD actually succeeds to erase the flash memory (which is confirmed in the output to the flash erase_check 0 command)

The bogus error message is an unsolved problem in OpenOCD, described here:
http://openocd.zylin.com/#/c/5522/

[Nguyen Hoan Hoang]

The board might be protect.  You need to use nrfjprog to unprotect it first.

[kristof.mulier]

Hi Nguyen Hoan Hoang, thank you for your answer. It's my first Nordic chip I'm working with. How exactly do you use nrfjprog to unprotect the chip first?

[Nguyen Hoan Hoang]

kristof.mulier You can use the IDAP-Link CMSIS-DAP JTag with OpenODC to flash and debug all ARM Cortex-M series that is supported by OpenOCD including the nRF series.  For support nRF91 series, use this version of OpenOCD sourceforge.net/.../ 

[kristof.mulier]

Hi Nguyen Hoan Hoang, that's very interesting.I bought an SWDAP probe some time ago from L-Tek (see https://www.l-tek.com/web-shop/l-tek-swdap-interface/). The SWDAP is an open-source probe, designed by ARM (See https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/tree/master/DAPLink/Probes/SWDAP) and produced and distributed by L-Tek. The firmware on this probe is DAPLink, which is an open-source firmware written by ARM (See https://github.com/ARMmbed/DAPLink).

In what way is this SWDAP probe different from the IDAP-Link CMSIS-DAP JTag that you mention?

[Nguyen Hoan Hoang]

The IDAP-Link firmware is not the open source version.  It is written from scrap based on the CMSIS-DAP specs directly and support both mode SWD and JTAG.  It also has command line program IDAPnRFProg made specifically for the nRF51 & nRF52.  It allows ffashing softdevice + app + dfu without using mergehex.  It can parallel flash multiple boards at the same time.  Which is great for production programming.  The IDAP also support a console flashing builtin which allows you to use a dump terminal such as Coolterm to flash nRF51 & nRF52.  nRF91 serie support will come later.  More over it also can flash from an inserted MicroSD (bottom of the board).  A UART to USB bridge that can handle up to 3MBaud. 

 

[kristof.mulier]

Hi Nguyen Hoan Hoang, that's indeed very interesting. Is the IDAP-Link device opensource hard- and software? We can certainly add support for this device to our IDE. I suppose the IDAP-Link device works properly with OpenOCD, right? Please feel free to contact me directly on:
[email protected]
or on my other e-mail:
[email protected]
Hope to hear from you soon.

[Edvin]

 Hello,

kristof.mulier said:

Can we get the permission for this?

For legal questions, please contact your RSM. Send me a message here on DevZone, and I can provide you the contact information.

You don't need to use nrfjprog. This is just a layer on top of J-Link. I haven't used the layers below that much, but all in all, nrfjprog is just based on existing drivers.

BR,

Edvin