Hi there,
I m struggling to investigate a weird problem.
Problem:
In short, the problem is : the OTA bootloader part in EEPROM is corrupted.
The device can't boot up and doesn't repond to GPIO interrupt. LED keesp lighting on all the time which should blink after boot up.
When I try to read CS configurations of bootloader using CsConfig.exe, it reported like this:
What I tried:
I compared image file dump from devices being investigaed with good image file, seems there are some continious difference from 0x000026 to 0x000058:
Information about EEPROM map:
mostly followed examples from CSR_uEnergy_SDK-2.6.1.7
Application NVM settings in csr101x_A05.keyr:
&nvm_start_address = 4100 // Default value (in hex) for EEPROM
&nvm_size = 40 // Default value(number of words)
Will be much appreciate if someone could share some thoughts on this.
B.R.
Here I uploaded the screenshots which is not loaded in my last post:
This indeed is a wierd issue. Looks like some section of the EEPROM has 0xbbbb over writted by some rouge process.
What is the occuerence of this issue? How frequently is this seen? Can this be reproduced?
What is the version of the OTA? v6 or v7?
The latest available SDK for CSR1010 is 2.6.3.12. Recommend to use the same.
Hi abhgos,
Thanks for paying attention here.
Q : What is the occuerence of this issue? How frequently is this seen? Can this be reproduced?
A : Till now I just found 2 bad samples of 1000 pcs devices. I am still working to find out how to reproduce this phenomenon.
Q : What is the version of the OTA?
A : It's V7.
Q : The latest available SDK for CSR1010 is 2.6.3.12. Recommend to use the same.
A : Thanks for this advice. Will apply latest SDK to my legacy project later. But investigation with current SDK and project comes first.
In fact, the application has some chanes to manipulate NVM, such as store bonding information and some other user data.
Is it possible the NVM interface have some bugs to cause such NVM damage in bootloader code sector?
Or would this be related to power supply chain?
B.R.
Hi,
As you can understand, its really difficult to figure out a actual root cause here. Lot of testing is needed to conclude.
The EEPROM read write is realtively stable and I don't think that a power supply can cause this. Is the memory corrupted in the same place in both the faulty devices? If yes, this would strongly indicate some bug with the firmware.
However, it will be nice to add some protection in the situation where the Application does NVM Write calls. The write address should fall within some specified limits.
These are the only thoughts coming to my mind now.
Thank you abhghos,
Q : Is the memory corrupted in the same place in both the faulty devices? If yes, this would strongly indicate some bug with the firmware.
A : yes, it's corrupted in the same place in both faulty devices.
Yes, this makes sense. but seems the API NvmWrite only takes offset as NVM address.
If it takes an big offset out of NVM size, it only should corrupt Application 1 or Application 2 area. More likely, if offset out of NVM size, it should return an error message like "nvm_status_invalid_offset".
extern sys_status NvmWrite(const uint16* buffer, uint16 length, uint16 offset);
NVM memory map:
0x0000 CSR OTA Update bootloader
0x4000 CSR OTA Update Shared Data
0x4100 Application NVM Store
0x4200 Application 1
0xa100 Application 2
0x10000 End of address space
BTW, I post the NVM read/write wrapper code in my project: