• State Verified Answer
  • Replies 3 replies
  • Subscribers 72 subscribers
  • Views 779 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 324903
Options

Is it impossible to SWD debug the pca10059?

thejeffcooper

Hi all,

I recently bought two nrf52840 dongles (pca10059), and I haven't been able to connect to them with my SWD debugger. I have several other nrf52 boards (52840 and 52833), both commercial development boards and custom PCBs, and I've been able to debug all of them just fine over SWD. When I connect power, ground, SWDIO, and SWDCLK on my dongles, though, I can't seem to do anything: openOCD connects, but none of the debug commands (halt the CPU, inspect memory location, program into flash) work. I observed this behavior on both a dongle that I'd been using for a few days and on one fresh out of the package.

The only clue I seem to have is in the openocd output when it starts up: on a working board (this output is from an nrf52833 custom PCB, but nrf52840 should be the same), I see this in the startup log:

Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints

whereas on the dongle, I see

Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints

Is there some special consideration for the pca10059 that I haven't thought of? I've tried both USB-powering the board (with a shared-ground to the debugger) as well as changing the jumpers  to use external power (as described in the documentation) and powering directly with 3.3v. Does the stock bootloader enable APPROTECT, and if so, how can I disable it? I don't currently have access to a J-Link, though I could maybe try the raspberry pi based method described here (I haven't yet, since I'll need to track down a pi if that's necessary).

Hopefully I'm just missing something obvious, but I have no idea what it might be.

Thanks!

Parents
  • 0

    An update (and some notes for anyone similarly frustrated): the root cause of my problem seems to be errata 249.

    I was able to figure out what was going on after a lot of trial and error. First, I flashed black magic onto my st-link. This gave it the ability to connect to the CTRL-AP and run the erase_mass command (similar to the nrfjprog --recover option, I believe), which wiped the flash and UICR registers. I still strugged a lot after this, though, until I found errata 249 for revision 3 of the nrf52840, which introduced a change in the debug port behavior. My frustration came from not being able to connect the debugger to a freshly-erased chip after a pin reset, since the UICR.APPROTECT register resets to 0xFF ("Disabled"). I found that while I could then use the debugger as normal, I could only do so until the next power cycle of the dongle, when it would go back to being locked. The errata says UICR.APPROTECT to 0x5A (HwDisabled) and then modify the firmware to set APPROTECT.DISABLE to 0x5A (SwDisable), so to keep the debug port open reliably, I had to do just that.

    To make things more frustrating, gdb/blackmagic wouldn't let me write to the UICR registers, since the memory map presents them as flash and "Writing to flash memory forbidden in this context". In order to set UICR.APPROTECT, I had to create a .hex file (noapprotect.hex) and then merge it with my bootloader's hex file (in this case, I was using the Adafruit nrf52 bootloader):

    hexmerge.py pca10059_bootloader-0.8.3_s140_6.1.1.hex noapprotect.hex -o combined.hex

    and then load it using gdb's `load` command. After that, I could upload a firmware that set NRF_APPROTECT->DISABLE = APPROTECT_DISABLE_DISABLE_SwDisable (which is equivalent to *(uint32_t*)(0x40000558) = 0x5A; in older versions of nrf5 SDK, like the one distributed with platformio that I'm using). After that, debugging works reliably after an unplug/replug or other reset. I may try to get a patch submitted to the Adafruit bootloader that includes the errata 249 workaround, but for now at least I have a working solution.

    I do have one remaining question: is it intended behavior that UICR.APPROTECT=0xFFFFFFFF (the default after a flash erase) makes it impossible to use a debugger, regardless of the value of APPROTECT.DISABLE ?

Reply
  • 0

    An update (and some notes for anyone similarly frustrated): the root cause of my problem seems to be errata 249.

    I was able to figure out what was going on after a lot of trial and error. First, I flashed black magic onto my st-link. This gave it the ability to connect to the CTRL-AP and run the erase_mass command (similar to the nrfjprog --recover option, I believe), which wiped the flash and UICR registers. I still strugged a lot after this, though, until I found errata 249 for revision 3 of the nrf52840, which introduced a change in the debug port behavior. My frustration came from not being able to connect the debugger to a freshly-erased chip after a pin reset, since the UICR.APPROTECT register resets to 0xFF ("Disabled"). I found that while I could then use the debugger as normal, I could only do so until the next power cycle of the dongle, when it would go back to being locked. The errata says UICR.APPROTECT to 0x5A (HwDisabled) and then modify the firmware to set APPROTECT.DISABLE to 0x5A (SwDisable), so to keep the debug port open reliably, I had to do just that.

    To make things more frustrating, gdb/blackmagic wouldn't let me write to the UICR registers, since the memory map presents them as flash and "Writing to flash memory forbidden in this context". In order to set UICR.APPROTECT, I had to create a .hex file (noapprotect.hex) and then merge it with my bootloader's hex file (in this case, I was using the Adafruit nrf52 bootloader):

    hexmerge.py pca10059_bootloader-0.8.3_s140_6.1.1.hex noapprotect.hex -o combined.hex

    and then load it using gdb's `load` command. After that, I could upload a firmware that set NRF_APPROTECT->DISABLE = APPROTECT_DISABLE_DISABLE_SwDisable (which is equivalent to *(uint32_t*)(0x40000558) = 0x5A; in older versions of nrf5 SDK, like the one distributed with platformio that I'm using). After that, debugging works reliably after an unplug/replug or other reset. I may try to get a patch submitted to the Adafruit bootloader that includes the errata 249 workaround, but for now at least I have a working solution.

    I do have one remaining question: is it intended behavior that UICR.APPROTECT=0xFFFFFFFF (the default after a flash erase) makes it impossible to use a debugger, regardless of the value of APPROTECT.DISABLE ?

Children
Related
Terms of service