Dear support team,
I am trying to write something into OTP.
I am using the function "otp_write_words" to write OTP.
I wrote some data into the address 0x7F8FDF0 in my code as following steps...
1. Write 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
2. Read the address, got 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 ==> correct
3. Write 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02
4. Read the address, got 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 ==> correct, because (0x01 | 0x02) = 0x03
However, I found that sometimes it is weird.
I have written data into the OTP, but after reading, It became to 0x00. Some bytes which I wrote 0x00, but it became 0x80.
1. Write 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x11
2. Read the address, got 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x11 ==> correct
3. Write 0x00 0x00 0x00 0x00 0x00 0x00 0x22 0x00
4. Read the address, got 0x00 0x00 0x00 0x00 0x00 0x80 0x22 0x00 ==> incorrect, It should be 0x22 0x11 and a byte became 0x80??
Why? I have no idea.
After rounds of reading and writting, I can't read anything from OTP.
I traced the code, I found it got stuck in "ASSERT_WARNING_OTPC_MODE(HW_OTPC_MODE_STBY);" of "hw_otpc_manual_read_on" function.
How can I recover it?
By the way, I use Product Line Tool to write some data such as "Trim Value for the XTAL16M oscillator".
Should I write some code to read it and set the value?
Thanks a lot.
Hi stanley_yeh,
Are you sure that this is where the code ends up in the assertion that you are describing ? if you have been reading and writing on the same addresses of the device i would expect that the device would end up in Hardfault and not in any kind of assertion. The OTP provided is designed to be written only once and not be over written, it has mechanisms that provide an error detection and in case of a double error bit that would result in a hardfault and also it provides a mechanism that one could correct up to 8 words in the OTP. So to sum up, you have 8 additional words maximum spare with which you can correct the OTP's entry, after that you simply cannot. If in the entry there are errors, they are detected by the OTP's logic and the system ends up in hard fault, since the error in OTP read, generates a error on the AHB BUS.
Thanks MT_dialog
Hi MT_Dialog,
Thanks for your response.
I am sure the code ends up in the assertion.
If I comment out the assertion, it will end up in reading OTP (e.g. memcpy(&dev_bdaddr, (uint8_t *) OTP_HDR_BDADDR_BACKUP_ADDR, sizeof(dev_bdaddr));)
Sorry, one more question, If I use Product Line Tool to write some data such as "Trim Value for the XTAL16M oscillator".
Should I write some code to read it and set the value? I can't find any function read the value in my SDK.
Thank you very much.
Hi stanley_yeh,
I ve tried to replicate what you are experiencing and by following your instructions i am not able to force the device to be stuck at that point, the assertion that occurs is because the OTP is not in STANDBY mode when you are performing the reading of the device, you can check through the memory window what is the value of the OTPC_MODE_MODE of the OTPC_MODE_REG and causes that, perhaps due to a previous command. Normally before the hw_otpc_manual_read_on() is executed the hw_otpc_init() function sets the device in HW_OTPC_MODE_STBY.
I dont quite get the second question though, the prod test tool supports some commands, including the trimming of the Crystal commands (read, write, test, etc), the trimming of the crystal should be done during production, so you should be able to use the commands of the prod_test.exe through a batch file in order to find and burn the trimming value of the XTAL you have used.
Thanks MT_dialog
Hi MT_dialog,
Ummm, I can't read data in OTP even I use smartsnippets. Maybe I did something wrong.
我改变了一个other board and it works good. I will observe this problem, thanks.
I apologize for not making my points clear.
My question is, if I use PLT(production line tool, not prod test tool, as I know, they're different, right?) to do some calibration, the result will be written in OTP header, right?
After using PLT, when the device boots, bootloader in ROM moves the code from FLASH to SRAM and application startup, which function will read the data from OTP and use the value of calibration?
In SDK, I just find the "read_otp_header()" function will read OTP, but just read bd address, IQ trim values and low power clock source.
Which function will read other data such as trim value for the XTAL16M?
Thanks a lot.
Hi stanley_yeh,
生产线工具所用的板mass production, the prod_test tool is the fw that is used by the GU (Golden Unit) and yes there is the functionallity to calibrate and burn the trimming value or the crystal in the OTP Header field. When the device is ready to go (in your case calibration value calculated and applied in OTP and fw in the flash) and boots up, the calibration value initially is applied to the XTAL trim register, this kind of functionallity is performed via ROM booter upon start up and not via the SDK if that is what you are looking for.
Thanks MT_dialog
非常感谢。:)