I'm working with a customer that thinks may have found an issue with the SNV implementation.
We were having reliability and corruption issues on the SNV flash. Doing some digging I think I found a bug and created a workaround.
Testing done on Simplelink 3.20.0.68 on the CC2642R2. We tested the latest SDK and the error still occurred, but we did not deep dive that code.
Summary of My fix:
Do a “osal_snv_compact(len);” before I do a “osal_snv_write”
Issue:
Inside nvoctp.c running the function “NVOCTP_findItem” you loop on ofs until it is successfully written on the size becomes less than “NVOCTP_PGHDRLEN + NVOCTP_ITEMHDRLEN”. The ofs is passed through as NVOCTP_pgOff. When the ofs/ NVOCTP_pgOff size is too large the function falls into a corruption error and attempts to fix the corruption through “NVOCTP_compactPage(NVOCTP_activePg);”. This will fix the NVOCTP_pgOff but the “ofs” is not updated so the function continues to loop. From this loop doing a “ofs -= NVOCTP_ITEMHDRLEN;” causes the offset to slowly shrink and (I think) causing corruption. This locks the code until this loop falls out, that can take ~10s.
Recommendations:
Do the compression/size check as part of the “osal_snv_write” and return status early on in the check. Also have a status message API for the SNV flash for when the memory has been written and when it is ready to take a write. Also be able to read out SNV size used.
There may be another way we should be using SNV flash that would correct this error condition but we followed the example code.
Have we observed this issue before? Do we have any suggestions for the customer?
Thanks,
Stuart
