Getting Write verify failed every time when try to debug or write without erase.

[Jithin A]

Hi,

We are working with nRF5340 with SDK v2.5.2.

Each time we try to program the board, we get below error.

[ #################### ]  12.131s | Erase file - Done erasing                                                          
[ #################### ]   1.269s | Program file - Done programming                                                    
[ #################### ]   1.299s | Verify file - Done verifying                                                       
[ #################### ]  14.504s | Erase file - Done erasing                                                          
[ #################### ]   2.654s | Program file - Done programming                                                    
[error] [ Client] - Encountered error -160: Command verify_file executed for 2719 milliseconds with result -160        
[error] [  nRF53] - Failed while performing 'Verify' operation on target address 0x00FF8128.                           
-160: Data does not match in address range [0x00FF8128 - 0x00FF8177] (APP UICR)
Expected byte value 0xFF but read 0xFC at address 0x00FF8150.
[error] [  nRF53] - Failed while verifying device. -160: Data does not match in address range [0x00FF8128 - 0x00FF8177] (APP UICR)
Expected byte value 0xFF but read 0xFC at address 0x00FF8150.
[error] [ Worker] - Data does not match in address range [0x00FF8128 - 0x00FF8177] (APP UICR)
Expected byte value 0xFF but read 0xFC at address 0x00FF8150.
ERROR: Write verify failed.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 25: nrfjprog --program 'd:\project\..\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex' --sectorerase --verify -f NRF53 --coprocessor CP_APPLICATION --snr 960130361

We do not see this error if we try Erase and Flash option from VS Code. We observe the same issue even with the nRF5340DK board.

This is very annoying us as we cannot debug or program without erasing. Please help us solving the issue.

We are using VS Code with NRF Connect extensions. SDK v2.5.2.

[Jithin A]

Any update on this?

Please let me know if any additional information is needed.

Thank you in advance

[Michal]

Hello,

Are you using a watchdog timer in your code by change?

Best regards,

Michal

[Jithin A]

Hi Michal,

Any update?

[Jithin A]

Hi.

Any update on this?

[Maria Gilje]

Hello,

I am starting to look into this from the beginning now because Michal is away. Sorry about the delay.

I will share a few things which caught my eye as I was reading through your original ticket and the replies.

Each time we try to program the board, we get below error.

Expected byte value 0xFF but read 0xFC at address 0x00FF8150.

From the error log I saw that the addresses in the logs are from the UICR for the application core, more specifically the UICR part which is handled by the Key management unit. The KMU documentation has a section on the intended usage which includes the required format for OTP (one-time programmable) write operations. My initial hypothesis is that when you flash without erasing, you write something to the UICR which has a wrong format. Please read the documentation on UICR and KMU and let me know if there is something which is not clear on those pages.

FATAL ERROR: command exited with status 25: nrfjprog --program 'd:\project\..\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex' --sectorerase --verify -f NRF53 --coprocessor CP_APPLICATION --snr 960130361

This error is a NrfjprogIniNotFoundError with the explanation that nrfjprog.ini is not found in the install folder. The proposed solution is to reinstall nrfjprog. More nrfjprog error codes can be found here.

---

After looking quickly over the nRF Connect for VS Code support information you attached I could not find any indicators for what causes the error.

Since the error only happens when you don't fully erase the chip, I want you to look over the documentation I linked for the UICR and KMU before we go further into other possibilities.

Best regards,

Maria

[Jithin A]

Hi Maria,

We are not able to solve the issue.

Can you educate me on the below error message.

WARNING: runners.nrfjprog: The hex file contains data placed in the UICR, which may require a full erase before reprogramming. Run west flash again with --erase, or --recover.

We are not writing anything into UICR and yet we see the above message. How come the hex contains data to be written UICR when we are not including anything to write on UICR. Please let us know if we are doing something wrong.

[Maria Gilje]

Jithin A said:

Can you educate me on the below error message.

The UICR is the address space 0x00FF8000-0x00FF8FFC. nrfjprog reads that there is data in the address space which is reserved for UICR. I get that you haven't purposefully configured anything to be written to UICR, so we need to find out if something unexpected has been configured for the UICR.

Finding out if there is a partition which uses the address space will help us to find out why nrfjprog sees data in the UICR. If you have a multi-image build, the partition manager will generate a partitions.yml file in the build folder. There you can read the addresses for every partition and check if one of them is configured within the UICR address space.

Is your application based on a sample from nRF Connect SDK? If yes: which?

[Jithin A]

Thank you for the response, Maria.

Maria Gilje said:

Is your application based on a sample from nRF Connect SDK? If yes: which?

Yes, and it is based on TFM Secure peripheral.

Maria Gilje said:

If you have a multi-image build, the partition manager will generate a partitions.yml file in the build folder.

Yes, and you are right I see OTP and provision partition residing in the address range.

Can you please explain why do we need these partitions? If it is safe to remove the partitions, how can we remove as I see it is generated every time the application is build.

Let me share you the partitions info.

otp:
  address: 0xff8380
  end_address: 0xff83fc
  region: otp
  size: 0x7c
provision:
  address: 0xff8100
  end_address: 0xff8380
  region: otp
  size: 0x280

[Maria Gilje]

Hello,

Thank you very much for your patience.

Jithin A said:

Can you please explain why do we need these partitions? If it is safe to remove the partitions, how can we remove as I see it is generated every time the application is build.

For TF-M, the OTP is used to store any data which should be provisioned at the factory. See more information here in our TF-M documentation.

The provision partition seems to be a bootloader addition. Are you using a bootloader in your application? See the relevant documentation for the nRF Secure Immutable Bootloader here.

Best regards,

Maria

[Jithin A]

Thank you, Maria, for enlighten me about the partitions.

Maria Gilje said:

Are you using a bootloader in your application?

--> Yes, we have integrated secure boot loader in our application.

Please guide me how to not to corrupt these partitions so that it boots properly, or we can debug without erasing the flash.

[Maria Gilje]

Hi Jithin,

I got back to your ticket quite late today, and I will need to give you a proper reply after the weekend.

Thank you for your continued patience with this, and I apologize for the delays.

Best regards,

Maria

[Maria Gilje]

Hi Jithin,

The TF-M: PSA template is a sample which has NSIB enabled by default. Do you get the same UICR error when flashing that sample to your board? If the sample flashes successfully without erasing, then please ensure that your project configures the NSIB like the PSA template sample does.

Best,

Maria