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]

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?

[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]

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

[erik.johnson]

Yep, will do!

[erik.johnson]

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.