nRF52833 (Custom Board) halts when JLink is connected

Update: 

Turns out it was an issue with the readback protection. We have a temporary fix of calling the following function at boot.

Is there a way to configure this in Kconfig or Devicetree? 

Original Post:

Hello!

We have just received a new revision of our device's PCBA and are having issues getting RTT output. 

When we program the board, it successfully flashes and runs. We can power cycle the board and it will come back on just fine. It also works fine during debugging, we get an RTT output and we can step through the program. 

However, when we have the JLink connected and run `JLinkExe` (or connect the nRF Connect SDK RTT Client) the board seems to get stuck in a reset state. The program doesn't run and doesn't recover when power cycled. The RTT client just says:

A second issue we have is that every 5 or so attempts at programming the device we are prompted that there is read protection and we need to recover the device. We are unsure why this is happening as we have not enabled read protection. 

Neither of these issues is present on our previous PCBA. The new PCBA is quite different from the old one but as the code is working correctly when debugging we don't think it's an assembly or schematic issue.

We would appreciate any ideas on the cause of these issues and any steps we can take to debug them. 

Many Thanks,
Archie

Parents
  • Hello,

    It seems like you have received the new revision of the nRF52833 ( rev.2 build code Bx0) which comes with a hardened approtect mechanism. With this revision you must write 0x5A (UICR_APPROTECT_PALL_HwDisabled) to UICR.APPROTECT  to make the debug interface stay open across resets (i.e. pin reset, power or brownout reset, watchdog reset, or wake from System OFF). Please refer to the IN149 Informational Notice v1.1 for a more detailed summary of the changes.

    Is there a way to configure this in Kconfig or Devicetree? 

    The SDK does not include code to set the UICR.APPROTECT register at runtime. Instead we recommend to run "nrfjprog --recover" when you receive a new board.  The --recover command will erase the flash through the CTRL-AP - Control access port and set UICR.APPROTECT = 0x5a.

    Your startup code will load the UICR.APPROTECT into the volatile  NRF_APPROTECT->DISABLE to prevent readback protection from enabling itself after a reset here: https://github.com/NordicSemiconductor/nrfx/blob/f5a9b04bacdd46cf6206f5813cd7e078ce5d553e/mdk/system_nrf52_approtect.h#L55

    Best regards,

    Vidar

  • Hi Vidar,


    Thank you for the reply. Are you saying that as long as you recover the device once, it will no longer have readback protection? If this is the case, it does not line up with what we are seeing. Without the code detailed in the above post, readback protection is reenabled each time we power cycle the device. I have checked and ENABLE_APPROTECT has not been defined. 

  • Hi,

    Yes, correct. What's important to note is that Jlink commander (jlink.exe on Windows) will erase the chip through the CTRL-AP when it disables the readback protection, but not set the UICR.APPROTECT register to disable it permanently like nrfjprog --recover does. This means the readback protection will become re-enabled again as soon as you perform a power or pin reset.

    You can run the following command to check if UICR.APPROTECT is set to UICR_APPROTECT_PALL_HwDisabled:

    $ nrfjprog --memrd 0x10001208

  • Something isn't working correctly for me. When I run the following commands:
    nrfjprog --program build/zephyr/zephyr.hex --recover --verify -f NRF52 --snr 821006534

    nrfjprog --run

    nrfjprog --memrd 0x10001208

    I get a readback protection error unless I include the code in my original post. It seems that the nrf startup code isn't disabling the soft readback protection. 

  • Please check if your nrfjprog installation is up to date. Older version will not recognize this new chip revision. 

Reply Children