nrfjprog still not quite flashing HEX files in Non-Secure flash

[erik.johnson]

There is a marked improvement in the handling of TrustZone in nrfjprog 10.11.0 and 10.12.00, but it seems it's still not quite all the way there. I can do:

nrfjprog --memrd 0x00010000

nrfjprog --memwr 0x00010000 --val 0x00000000

and am able to read and write to the Non-Secure region of flash, which was not the case previously. However, if I try to program that region with a HEX file:

nrfjprog --program [file] --sectorerase

it'll still fail with the usual "The operation attempted is unavailable due to readback protection..." The HEX file programs correctly when flashing without Secure being locked out, and the first line should be properly specifying the starting address:

:020000040001EF

So, seems like there's still some operation in the pipeline for programming that isn't in the memory read/write pipeline that's preventing the programming from happening. My own lower-level programming tool that uses the pynrfjprog library and the debugger registers still works with the setup and file, so it shouldn't be an issue with either.

[Simon]

I was not able to reproduce this. Could you give a detailed step-by-step on how to reproduce it?

Best regards,

Simon

[erik.johnson]

Well, we just have a Secure firmware image that writes NRF_UICR->SECUREAPPROTECT to prevent Secure debugger access. We also have a Non-Secure firmware image running in the region that the Secure firmware sets up (NRF_SPU_S->FLASHREGION).

[Simon]

Hello Erik,

I'll just inform you that I'll look into this the next couple of days.

[erik.johnson]

Hi Simon,

Sounds good!

One additional thing I've found that might make testing it on your end a little easier (won't need to deal with flashing a HEX file) is that the behavior also exists with trying to erase a page:

nrfjprog.exe --erasepage 0xb0000
Erasing addresses 0xB0000 to 0xB0FFF.
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

But I can actually dump the contents of the entire page out with the read:

nrfjprog.exe --memrd 0xb0000 --n 0x1000
0x000B0000: 00000000 00000000 00000000 00000000   |................|
0x000B0010: 00000000 00000000 00000000 00000000   |................|
0x000B0020: 00000000 00000000 00000000 00000000   |................|
0x000B0030: 00000000 00000000 00000000 00000000   |................|
0x000B0040: 00000000 00000000 00000000 00000000   |................|

So there appears to be some check done in the --erasepage and --program operations that isn't done with --memrd (or --memwr for that matter).

[Simon]

I talked to a developer internally and got informed this is a bug. An internal ticket is created. I'll keep you updated.