unlocking NRF52480

Dear all,

I have pca10059 nrf52480 dongle which I accidentally erased and I could not upload any elf file to run moreover it was not blinking red anymore, no presence in system.

I managed to restore the bootloader with this procedure:

https://devzone.nordicsemi.com/f/nordic-q-a/87495/nrf52480-dongle-bricked-after-recover-in-openocd/365842

Thenafter, the dongle started to flash red again and I could flash the dongle with my custom blinky example and the diode was blinking again.

The problem I am facing now is, I want to have a look at the running process via OpenOCD, but anytime I start openocd with this command:

openocd -f rpi_as_debugger.cfg -c "transport select swd" -c "adapter speed 100" -f target/nrf52.cfg

I get following problem:

(THE DONGLE IS RUNNING JUST FINE, I CAN SEE THE DIODE BLINKING, BUT AFTER FIRMWARE RESTORATION, IT SEEMS THE CHIP IS LOCKED, BUT WHY? AFTER I RECEIVED THE DONGLE FROM MOUSER, I COULD EASILY DEBUG THE SAME EXAMPLE AND OPENOCD WAS NOT PRINTING ANY PROBLEM, ANYWAY I AM USING SWD OVER RASPBERRY)

Is the chip detecting any internal error at startup being the reason it gets locked?

Open On-Chip Debugger 0.11.0+dev-00651-g9de084e00 (2022-04-24-10:22)
Licensed under GNU GPL v2
For bug reports, read
openocd.org/.../bugs.html
BCM2835 GPIO nums: swclk = 24, swdio = 25

swd
adapter speed: 100 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1001 kHz
Info : SWD DPIDR 0x2ba01477
Error: [nrf52.cpu] Could not find MEM-AP to control the core
****** WARNING ******
nRF52 device has AP lock engaged (see UICR APPROTECT register).
Debug access is denied.
Use 'nrf52_recover' to erase and unlock the device.

Warn : target nrf52.cpu examination failed
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections

During firmware restoration, I was also facing this, which I haven't a clue what it might be:

Warn : [nrf52.cpu] target was in unknown state when halt was requested
Info : SWD DPIDR 0x2ba01477
Error: Wrong parity detected

Thank you

Parents
  • Hello,

    The OpenOCD is not really a tool that we support, and I am not in any way familiar with it. But looking at the log, it may look like APPROTECT is enabled. In that case, you need to recover the nRF52 (which will also delete the flash again).

    So I guess that if you want to use this programmer tool, you need to program your application directly, or create your own bootloader which doesn't enable the approtect. 

    For the dongle, and programming it using programmers in general (although not specifying the OpenOCD), I can recommend this blog post:

    https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial

    Please see the section: "Using an external debugger" in particular.

    Best regards,

    Edvin

  • Thank you for your reply, could you please tell me whether APPROTECT is enabled by default?

    The thing is, I can recover the nrf52, it unlock the device and erases all. But once I flash the official bootloader again, it became locked again and you see the enclosed printout of OpenOCD, it is after flashing the firmware. The dongle works, I can flash applications, but it is locked. Even without any application, only with bootloader flashed (the dongle is blinking with red LED diode), it already is locked, at least according to OpenOCD.

    My goal is to, unlock the device, reflash the bootloader and than unlock it again without erasing it and reflashing the bootloader, since I think reflashing of bootloader makes it locked again.

    When I received the dongle, it looked like it was unlocked from factory, so I want to revert it to the same state as it was when I purchased it.

  • Dear sir, I am a complete newbie in microcontrollers.I just needed to unlock it to have debugging capability of the dongle via SWD.

    Before the accident,I could debug the code easily,now I have to add these unlocking lines of code beforecmy code runs.I am fine with that anyway.I was just curious whether ir is possible to unlock the device without those lines of code.I had an idea to dump factory firmware from my another dongle which is unlocked from factory a flash the locked dongle,but I am wondering why this procedure does not work as the devices are identical,but hardware versions are different.

Reply
  • Dear sir, I am a complete newbie in microcontrollers.I just needed to unlock it to have debugging capability of the dongle via SWD.

    Before the accident,I could debug the code easily,now I have to add these unlocking lines of code beforecmy code runs.I am fine with that anyway.I was just curious whether ir is possible to unlock the device without those lines of code.I had an idea to dump factory firmware from my another dongle which is unlocked from factory a flash the locked dongle,but I am wondering why this procedure does not work as the devices are identical,but hardware versions are different.

Children
  • It sounds like there was a different bootloader.hex file flashed on the dongle before you erased it. One that turned off the APPROTECT. I guess the bootloader file from the first link doesn't have this patch. 

    However, the dongle is not really a development board, as it doesn't have a debugger. This is why it has a bootloader in the first place. The bootloader is a way to update the FW on the dongle without a debugger. 

    If you have a programmer that you can use on the dongle, I suggest you just erase the bootloader, and debug without the bootloader being present. Then, when you are happy with your application, you can flash the bootloader back in together with the application (and softdevice/MBR) if you want to keep the possibility to update FW without a debugger/programmer. 

    Another option would be to build your own bootloader. The bootloader on the dongle is heavily based on the nRF5 SDK\examples\dfu\open_bootloader\pca10059_usb\ and then you can apply the fix from here:

    https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/working-with-the-nrf52-series-improved-approtect

    ("fix", as in disabling the approtect in your bootloader code, e.g. in main.c).

    Debugging is usually easier when a bootloader is not present either way, so I suggest you just add it when you are done developing.

    Best regards,

    Edvin

Related