Can't change ERASEPROTECT.DISABLE value

[erik.johnson]

If I write a value to ERASEPROTECT.DISABLE -- which itself works, as I'm fully able to perform the mass erase by writing the same value using the debugger -- I can't seem to write a new value to the register during the same boot. It presumably isn't flash-based, since it needs to be written each boot. Is this specifically being prevented by the core? Is there a way to "reset" the value and write a new one, assuming ERASEPROTECT.LOCK hasn't been set?

[Øyvind]

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

[erik.johnson]

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.

[Øyvind]

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. */

 

erik.johnson said:

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!

 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.

[erik.johnson]

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!

[Øyvind]

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

[erik.johnson]

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.

[Øyvind]

erik.johnson said:

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

 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