nRF51822 - Firmware becomes corrupt after extended use in field - reflashing fixes it.

[Mahonroy]

Hello, we are currently using the nRF51822 chip, and have roughly 1000 units of this particular device out in the field. After a few months of use, approximately 20 of these devices begin to randomly freeze. Power cycling or resetting the device will allow the device to run for a few minutes, up to a few hours max before freezing again.

If we re-flash the firmware to the device, this fixes the device and it will now run properly again.

We are beginning to get more and more complaints on this issue, and we are starting to think something is seriously wrong here.

Is it possible the firmware that is loaded onto the nRF51822 can become corrupt after a while? Is there a way we can compare the loaded firmware with our hex file somehow to see if it has become corrupt?

Are there any other tips we can try to do to figure out this problem?

We are using Keil uVision for the firmware development and flashing of devices. The SDK version is: nRF5_SDK_11.0.0_89a8197

This particular project is fairly simple, it consists of using the SPI slave library (the nRF51822 is acting as a slave for receiving/sending data back and forth between another microcontroller), it uses a 3ms timer, and it sends/receives payloads using the proprietary RF protocol.

Thanks, and any help or advice is greatly appreciated!

[Susheel Nuguru]

Hi Matt,

Is it possible the firmware that is loaded onto the nRF51822 can become corrupt after a while

If your application is doing a flash write and if it has a bug that triggers not so often, then it might write to a wrong memory location and could corrupt the code. Since you said that reflashing solves the issue, this means that the flash did not into any bad state.

 

Is there a way we can compare the loaded firmware with our hex file somehow to see if it has become corrupt?

try the command "nrfjprog --readcode <path_to_save the file>

Then you can compare it with the original hex to see if your application or softdevice code area has changed. I think this will be a very good test.

Also can you give me the laser markings on your nRF chip for me to check how old that version is. 

[Mahonroy]

Hi Aryan, thank you for the response!

This particular device is not writing to flash memory space from within the firmware.

Thank you for the nrfjprog command, I will give this a try on the next return we get.

I took a photo of the markings, I hope you can make them out?

[Susheel Nuguru]

Hi Matt,

When you read the memory using nrfjprog just after flashing and the corrupted state, please attach those hex files here along with the address range of your application. That will help me understand which memory areas are getting corrupted and can narrow it down to the library or application that owns that memory block..