Can't change ERASEPROTECT.DISABLE value

RE: Can't change ERASEPROTECT.DISABLE value

Øyvind — Tue, 08 Sep 2020 11:48:10 GMT

[quote user="erik.johnson"]Any word on the nrfjprog stuff yet? That's a far more important issue for us to get figured out.[/quote]

It's a known limitation in nrfjprog, and unfortunately no workaround yet. According to the nrfjprog team there will not be a fix until after next release.

Sorry for the inconvenience this may cause.

Kind regards,
Øyvind

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Mon, 07 Sep 2020 13:18:48 GMT

Okay, thanks for confirming the behavior I was seeing.

Any word on the nrfjprog stuff yet? That's a far more important issue for us to get figured out.

RE: Can't change ERASEPROTECT.DISABLE value

Øyvind — Mon, 07 Sep 2020 12:23:59 GMT

Hi Erik,

Our system architecture group reports that you are correct, and that this a Write Once register. Currently no fix available unfortunately.

Kind regards,
Øyvind

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Fri, 04 Sep 2020 12:56:10 GMT

Hopefully someone will have some more ideas on how to get the nrfjprog programming working.

As for the NVMC fields, I was mostly just talking about NVMC->CONFIGNS and how the NVMC peripheral hadn't been set to Non-Secure (in the SPU->PERIPHID[n].PERM registers). Like I said before, though, even after setting the permission to Non-Secure nrfjprog still isn't working.

Looking at nAN41, it seems like nrfjprog/a debugger should be fully capable of programming the Non-Secure flash using the DAP. I'm definitely not experienced enough with debuggers to be able to quickly put together a custom DAP script to accomplish the programming, so I'll wait to hear what the Nordic team has to say.

Thanks!

RE: Can't change ERASEPROTECT.DISABLE value

Øyvind — Fri, 04 Sep 2020 06:43:57 GMT

Thanks for the feedback! This is valuable information that I will forward to our R&D team to verify behavior.

Investigating some more around the ERASEPROTECT, I found the following from modules\hal\nordic\nrfx\mdk\nrf9160_bitfields.h

/* Register: CTRLAPPERI_ERASEPROTECT_LOCK */
/* Description: Lock register ERASEPROTECT.DISABLE from being written until next reset */

/* Bit 0 : Lock register ERASEPROTECT.DISABLE from being written until next reset */
#define CTRLAPPERI_ERASEPROTECT_LOCK_LOCK_Pos (0UL) /*!< Position of LOCK field. */
#define CTRLAPPERI_ERASEPROTECT_LOCK_LOCK_Msk (0x1UL << CTRLAPPERI_ERASEPROTECT_LOCK_LOCK_Pos) /*!< Bit mask of LOCK field. */
#define CTRLAPPERI_ERASEPROTECT_LOCK_LOCK_Unlocked (0UL) /*!< Register ERASEPROTECT.DISABLE is writeable */
#define CTRLAPPERI_ERASEPROTECT_LOCK_LOCK_Locked (1UL) /*!< Register ERASEPROTECT.DISABLE is read-only */

/* Register: CTRLAPPERI_ERASEPROTECT_DISABLE */
/* Description: Disable ERASEPROTECT and perform ERASEALL */

/* Bits 31..0 : The ERASEALL sequence will be initiated if value of KEY fields are non-zero and KEY fields match on both CPU and debugger side */
#define CTRLAPPERI_ERASEPROTECT_DISABLE_KEY_Pos (0UL) /*!< Position of KEY field. */
#define CTRLAPPERI_ERASEPROTECT_DISABLE_KEY_Msk (0xFFFFFFFFUL << CTRLAPPERI_ERASEPROTECT_DISABLE_KEY_Pos) /*!< Bit mask of KEY field. */

[quote user="erik.johnson"]Ahh, it appears there is an entire section I didn't know about in the NVMC section of the datasheet about specific steps to enable Non-Secure erase operations when Secure access is blocked. Hopefully all of this is my fault![/quote]

I assume it was the nAN41 you found? The NVMC field (along with APPROTECT and SECUREAPPOTECT) is described in the application note nAN41 - nRF9160 Production Programming under Troubleshooting, and the chapter Enabling device protection.

Will get back to you with more information as soon as I know more.

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Thu, 03 Sep 2020 15:00:55 GMT

So, looks like we weren't setting NVMC to Non-Secure-accessible in the peripheral permission registers, which was preventing the debugger from using those registers at all. I found that, if I allow Non-Secure access to them and didn't use ERASEPROTECT, I could set SECUREAPPROTECT and the debugger could still do its nrfjprog --recover process. But, if I turn ERASEPROTECT back on, nrfjprog will no longer do anything, including --program <file> --sectorerase, since it doesn't like that "readback protection" is on.

Since we don't want to allow anyone to erase our UICR and our Secure flash, we have to use ERASEPROTECT. Both 10.7.0 and 10.9.0 will not do the --sectorerase operation nor a manual --erasepage operation. Do you know what the "readback protection" is conditioned on? Is it something that could be bypassed in order to still do the page erase/flash write operations? I would think with NVMC now being Non-Secure-accessible this should work from the debugger.

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Thu, 03 Sep 2020 14:37:20 GMT

Ahh, it appears there is an entire section I didn't know about in the NVMC section of the datasheet about specific steps to enable Non-Secure erase operations when Secure access is blocked. Hopefully all of this is my fault!

Although the debugger should have access to these registers, since there are Non-Secure sets for them, so I would hope nrfjprog would already be setting these up if needed.

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Thu, 03 Sep 2020 14:21:35 GMT

Looks like not enabling ERASEPROTECT has no effect on the access to the Non-Secure flash. I removed that part of our setup (when enabling SECUREAPPROTECT) and nothing changed for either 10.7.0 or 10.9.0.

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Thu, 03 Sep 2020 13:54:20 GMT

The issue in this ticket isn't impacted by nrfjprog, since it's just code execution that's doing the reading/writing, but regarding the previous ticket, it looks like 10.7.0 has an issue with recognizing my device, which I don't think I've ever seen in 10.9.0. I've seen two behaviors when trying to reprogram the Non-Secure flash with 10.7.0:

nrfjprog.exe --program build/at_widget/zephyr/app_signed.hex --sectorerase
Parsing hex file.
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

and:

nrfjprog.exe --program build/at_widget/zephyr/app_signed.hex --sectorerase
ERROR: nrfjprog could not identify the target device. This may be due to an
ERROR: invalid family argument, a problem with your device, or nrfjprog may
ERROR: not yet support your device.
ERROR: Please check the family argument passed, or upgrade nrfjprog to a more
ERROR: recent version.

The first one occurs more often, but I've seen the second one show up a few times. I'm wondering if the first is occurring when the ARM core is running Secure flash firmware and the second is when the ARM core is running Non-Secure firmware. I'm going to play with that more to see if I can confirm it, and I'm also going to go back to 10.9.0 to see if I can reproduce the different behaviors.

At any rate, it seems like 10.7.0 still has issues with reprogramming Non-Secure firmware when APPROTECT has _not_ been set but SECUREAPPROTECT has been. It also seemed to have trouble reprogramming at all when SECUREAPPROTECT hadn't been set.

Another variable I didn't think to bring up is that ERASEPROTECT (in the UICR) is also being set to avoid allowing a mass erase of flash and the UICR (and only allowing a mass erase using the ERASEPROTECT.DISABLE register). It doesn't seem like this should prevent the debugger from being able to reprogram flash, though, since nrfjprog --program <file> --sectorerase should be doing individual page erases and writes.

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Thu, 03 Sep 2020 13:30:06 GMT

Yep, will do!

RE: Can't change ERASEPROTECT.DISABLE value

Øyvind — Thu, 03 Sep 2020 13:29:00 GMT

Hi Erik,
The issue might seem to be related to your previous support ticket (#255468). We've found a bug in nrfjprog, which might also be the root cause to what you are seeing in your last ticket.

Could you possibly test using an older nrfjprog e.g. 10.7.0?

Thanks!

Kind regards,
Øyvind

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Wed, 02 Sep 2020 13:51:24 GMT

Looks like DISABLE is being read as zero, even after writing to it (which I've verified is working, since I can write from the debugger to trigger the mass erase). The register description in the datasheet indicates it should be read/write.

So, clearly there's some under-the-hood handling of this register in the core that makes it act a little differently than other registers. This isn't any kind of a show-stopper, but it doesn't seem to behave the way I'd expect it to having read the datasheet.

RE: Can't change ERASEPROTECT.DISABLE value

erik.johnson — Wed, 02 Sep 2020 13:16:48 GMT

Right, but I'm not setting the LOCK bit at all, so I would expect to be able to write to DISABLE more than once. I was just trying to understand if it was able to be written to more than once, since it seems like a straightforward register.

I suppose I haven't checked, but is LOCK automatically set if I write to DISABLE?

RE: Can't change ERASEPROTECT.DISABLE value

Øyvind — Wed, 02 Sep 2020 13:12:49 GMT

Hello,

I've found the following in modules\hal\nordic\nrfx\mdk\nrf9160.h

/**
  * @brief CTRLAPPERI_ERASEPROTECT [ERASEPROTECT] (Unspecified)
  */
typedef struct {
  __IOM uint32_t  LOCK;                         /*!< (@ 0x00000000) Lock register ERASEPROTECT.DISABLE from being
                                                                    written until next reset                                   */
  __IOM uint32_t  DISABLE;                      /*!< (@ 0x00000004) Disable ERASEPROTECT and perform ERASEALL                  */
} CTRLAPPERI_ERASEPROTECT_Type;                 /*!< Size = 8 (0x8)

Kind regards,
Øyvind