Unresponsive device when flashing after disabling APPPROTECT

RE: Unresponsive device when flashing after disabling APPPROTECT

Federico — Mon, 18 Nov 2024 15:48:06 GMT

Oh ok I think that explains the issue.

Thanks!

RE: Unresponsive device when flashing after disabling APPPROTECT

Vidar Berg — Mon, 18 Nov 2024 14:18:13 GMT

The bootloader code always executes before the main application. The boot sequence is: MBR -> Bootloader -> SoftDevice -> Application. This means that the APPROTECT will be locked if a debugger attaches to the target after a reset, but before the bootloader branches to the main application.

[quote user="Federico"]This would suggest that the bootloader.hex code is running before flashing the app.hex file? Like in-between Additional Loads.[/quote]

The CPU is halted while the images are loaded. Execution is started after all hex files have been programmed.

RE: Unresponsive device when flashing after disabling APPPROTECT

Federico — Mon, 18 Nov 2024 12:48:49 GMT

Hi Vidar, yes I can confirm that by disabling the "bootloader.hex" Additional Load, it works fine. But we do need to load it.Based on what you said, I modified the bootloader project to run approtect_disable in main and now the issue seems to be gone.

This would suggest that the bootloader.hex code is running before flashing the app.hex file? Like in-between Additional Loads. Does that make sense? I'm still not sure I understood everything.

RE: Unresponsive device when flashing after disabling APPPROTECT

Vidar Berg — Mon, 18 Nov 2024 08:25:56 GMT

Thanks for the summary. The UICR will be cleared every time the bootloader FW is loaded. As a result the, the APPROTECT mechansim will not become unlocked until the program reaches the approtect_disable() call in app main(). To confirm this, you can remove the bootloader hex from the "Additional Load" field.

RE: Unresponsive device when flashing after disabling APPPROTECT

Federico — Fri, 15 Nov 2024 14:31:59 GMT

The short answer is that it only reaches that point after a recover, and the value is actually 0x5A. If I try to flash again, it will not even reach main, it gets stuck somewhere else.

I think I haven't explained myself clearly. I'll try to put a detailed sequence here:

nrfjprog --recover
Download & debug from segger. Segger is configured to "Additional Load" other hex files, which are the soft device, Bootloader and dfu settings, in that order.
This reaches main and executes without issues.
Goes through the approtect_disable function and leaves NRF_APPROTECT->DISABLE in 0x5A and NRF_UICR->APPROTECT in 0xFF.
Debugger works too, even through device resets.
Stop debugging session
Download & Debug again (no prompt to recover)
Now the execution never reaches main, it's stuck somewhere that appears invalid code, as I showed in the original post.
FORCEPROTECT shows as 1 (0x40000550)
NRF_APPROTECT->DISABLE shows as 1 (0x40000558)
NRF_UICR->APPROTECT shows as 0xFF (0x10001208)
Stop debugging session
Download and Debug again. This prompts for a recovery, press OK and now it works.

So, it seems to be working every other time. I was under the impression that I could only make it work again with "nrfjprog --recover", but now Segger is prompting me for recovery so it seems to work. Not sure what changed.

Thanks!

RE: Unresponsive device when flashing after disabling APPPROTECT

Vidar Berg — Fri, 15 Nov 2024 13:19:32 GMT

Hi,

It should be set to 0x5a after the approtect_disable() function has been executed. Can you place a breakpoint after this function call to confirm?

RE: Unresponsive device when flashing after disabling APPPROTECT

Federico — Fri, 15 Nov 2024 13:16:04 GMT

Hi,

Sorry I posted the wrong register. Here's the right one, I hope. 0x10001208 is set to 0xFF. What does this mean?

RE: Unresponsive device when flashing after disabling APPPROTECT

Vidar Berg — Fri, 15 Nov 2024 13:11:39 GMT

Hi,

The problem is the UICR.APPROTECT register @ 0x10001208. The programmer will erase the UICR section before writing to 0x10001014 and 0x10001018 when loading the bootloader image. However, the code snippet you posted should take care of this. Can you check if the UICR.APPROTECT is 0x5a?

RE: Unresponsive device when flashing after disabling APPPROTECT

Federico — Fri, 15 Nov 2024 13:04:24 GMT

Hi Vidar, thanks for the answer.

At that point, the register window in Segger shows this:

I didn't fully understand your logic regarding the bootloader overwriting the NRF_APPROTECT->DISABLE. Wouldn't it happen too in this sequence?:

nrfjprog --recover
download & debug from segger
- Load soft device
- load dfu settings
- load bootloader
- load app

If the bootloader overwritting NRF_APPROTECT->DISABLE is the issue, can I modify the bootloader project to have the 0x5A be part of the hex file that is being burned? I see the hex file includes contents for 0x10001014 and 10001018, but I couldn't find in the code where this is defined.

RE: Unresponsive device when flashing after disabling APPPROTECT

Vidar Berg — Fri, 15 Nov 2024 12:09:25 GMT

Hi,

The nrfjprog --recover procedure differs from the JLink unsecuring procedure in that it will also write 0x5A to the UICR.APPROTECT register and load a small FW image that will unlock approtect in SW (i.e. write 0x5A to the NV NRF_APPROTECT->DISABLE register) after the ERASEALL.

The problem is that the bootloader includes data in the UICR region (@0x10001014 and 10001018) which causes the UICR section to be erased when you program the bootloader image. This means the UICR.APPROTECT will be set to '0xff' again, causing 0xFF to be written to NRF_APPROTECT->DISABLE in your startup code before reaching main().

https://docs.nordicsemi.com/bundle/ps_nrf52840/page/dif.html

[quote user=""]After including this code, I no longer get the message and traces keep working even after a reset. However, if I try to download & debug again, the code doesn't run and the uC seems to be stuck at a random location:[/quote]

Are you able to read out the UICR.APPROTECT register at this point?

Best regards,

Vidar