Tool/software:
Hello,
we have some questions regarding the OTP programming behavior and would appreciate clarification.
# Main Question - Program the OTP - Step 5
We found a related discussion on the TI E2E forum:
e2e.ti.com/.../bq79616-q1-otp-programming
One takeaway from the discussion is:
'The OTP_CUSTx_STAT registers are only updated when the OTP pages are loaded, so only after a reset.
You need to perform the digital reset and successfully re-establish communication before you will get data from them.
However, the data in OTP_PROG_STAT will be lost after a reset, so you must read it before you send the reset.'
Could you kindly confirm that this is correct and corresponds to the trace below,
and thus confirms that we are executing the procedure correctly, while also indicating that the documentation is not correct?
It seems to work perfectly, but we want confirmation that this is indeed the correct and expected behavior.
Apologies if this is repetitive, but it might help others encountering the same issue.
As shown below, the expected OTP_CUST1_STAT value (0F) does not match the observed result (00), which contradicts the documentation.
-- 1) Unlock OTP programming
[IMPORTANT] OTP UNLOCK SEQUENCE DONE!!!
-- 2) Read OTP_PROG_STAT to verify unlock status
[SUCCESS] OTP_PROG_STAT should be 80 and is: 80
-- 3) Write to OTP_PROG_CTRL to start programming
[IMPORTANT] OTP PROGRAMMING STARTED!!!
-- 4) Wait till OTP programming finishes
[IMPORTANT] OTP PROGRAMMING FINISHED!!!
-- 5) Read out current state
[SUCCESS] OTP_PROG_STAT should be 01 and is: 01
[FAIL] OTP_CUST1_STAT should be 0F and is: 00
[SUCCESS] OTP_CUST2_STAT should be 00 and is: 00
-- 6) Issue digital reset and wait 10 = 0x02 soft reset
[IMPORTANT] Issue digital reset and wait begin
[IMPORTANT] Issue digital reset and wait end
-- Addition 1) Auto address after digital reset
Auto address done
-- Addition 2) Read out current state
[SUCCESS] OTP_PROG_STAT should be 00 and is: 00
[SUCCESS] OTP_CUST1_STAT should be 8F and is: 8F
[SUCCESS] OTP_CUST2_STAT should be 00 and is: 00
-- Addition 3) Fault summary
-- FAULT SUMMARY 0 --
Register Fault summary (0x052D) response (hex): 02
Register Fault summary (0x052D) response (binary): 00000010
Register Fault SYS (0x0536) response (hex): 10
Register Fault SYS (0x0536) response (binary): 00010000
Register Fault COMM1 (0x0530) response (hex): 00
Register Fault COMM1 (0x0530) response (binary): 00000000
Register Fault COMM2 (0x0531) response (hex): 00
Register Fault COMM2 (0x0531) response (binary): 00000000
Register Fault COMM3 (0x0532) response (hex): 00
Register Fault COMM3 (0x0532) response (binary): 00000000
Register Fault OTP (0x0535) response (hex): 00
Register Fault OTP (0x0535) response (binary): 00000000
Register Fault PWR1 (0x0552) response (hex): 00
Register Fault PWR1 (0x0552) response (binary): 00000000
Register Fault PWR2 (0x0553) response (hex): 00
Register Fault PWR2 (0x0553) response (binary): 00000000
Register Fault PWR3 (0x0554) response (hex): 00
Register Fault PWR3 (0x0554) response (binary): 00000000
# First Additional Question – OTP_SPARE vs. CUST_MISC
Documentation states:
'OTP_SPARE: These are spare OTP and shadow register bits that are implemented in the device.
These bits are included in the CRC calculation but do not perform any function or influence device behaviors.'
'CUST_MISC: Customer scratch pad.'
From our tests, there appears to be no functional difference between using OTP_SPARE and CUST_MISC for storing user-defined data.
Is there any functional distinction between OTP_SPARE and CUST_MISC?
# Second Additional Question – Factory Configuration Load Failure
The documentation states:
'If the OTP (either factory configuration default or value programmed in customer OTP space)
is failing to load after a device reset, the shadow registers will be loaded with the hardware reset default value instead.'
Under what circumstances could the factory configuration default fail to load?
Are there specific failure conditions that could cause this behavior?
Best regards,
Stefan
