• State Resolved
  • Locked Locked
  • Replies 61 replies
  • Answers 18 answers
  • Subscribers 62 subscribers
  • Views 2701 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ79616-Q1: OTP Programming

Yoshihiro Kato
Prodigy 30 points
Part Number: BQ79616-Q1
Other Parts Discussed in Thread: BQ79616

I followed the steps in Table 9-26 of datasheet 9.3.6.3.2 (OTP Programming), but operation 'b' was not executed. was not executed. and "c". The contents of step 5 differ from the data sheet.
Which is correct, the data sheet or the actual behavior?


Datasheet behavior
b. If page 1 is programmed, the OTP_CUST1_STAT[PROGOK], [TRY], [OVOK], and [UVOK] bits will be 1. Other bits are 0.
c. If page 2 is programmed, the OTP_CUST2_ bit is STAT[LOADED], [PROGOK], [TRY], [OVOK], and [UVOK] bits are 1. Other bits are 0.


Actual operation
b. and c.
OTP_CUST2_STAT: All bits are 0.
However, after performing Step 6, the same bit as in the data sheet becomes 1.

  • 0
    TI__Expert 7060 points

    Yoshihiro,

    What steps did you perform exactly? Could you share your code? After your performed step 6, what were the specific bits that were one? Could you list them out? 

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for reply.

    Sorry, Source code cannot be provided without our boss's approval.
    It is possible to provide an image of sending and receiving commands, but would it be difficult to investigate?

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    I do not need the source code. I just need to know what commands you sent and what data you received from the device.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    I got it. I will send you the log, so please wait until next week.
    The device we have is already programmed with both OTP page 1 and page 2.
    Is there a way to clear OTP data?

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    OTP stands for "One Time Programming". As the name suggests, you can only program it once and after you program it, the data cannot be changed. There is no way to clear or change either page on that device. 

    The errors you are seeing are because you have already programmed the OTP data. 

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    I got it, I'll collect logs using another device.

    So, I have one more question.
    I would like to know why OTP is implemented with 2 pages.
    What are the use cases of using both pages?

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    The two pages exist to provide redundancy and improve safety. If an error occurs when loading page 2 (which has priority), page 1 can be used as a backup.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,
    I see, normally page 2 is used, but in the event of an error, page 1 is used as a backup.
    We are currently preparing to collect the logs, so please wait a few days.

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    Prodigy 30 points

    Ben san,

    Thanks for waiting.
    I will show you the log, please check it.

    Best Regards.

    ***********

    1.Program the OTP(Page 1)

    Step1
    Send : 93 00 03 00 02 B7 78 BC 9B 6E <- a. Write data to OTP_PROG_UNLOCK1A to OTP_PROG_UNLOCK1D.
    Send : 93 00 03 52 7E 12 08 6F 4F 4C <- b. Write data to OTP_PROG_UNLOCK2A to OTP_PROG_UNLOCK2D.

    Step2
    Send : 80 00 05 19 00 3E 4F <- a. Read data from OTP_PROG_STAT.
    Recv : 00 00 05 19 80 3E 31 <- [UNLOCK] = 1. OK.

    Step3
    Send : 90 00 03 0B 01 D2 ED <- a. Write data to OTP_PROG_CTRL [PAGESEL][PROG_GO].

    Step4
    Wait tPROG= 100ms.

    Step5
    Send : 80 00 05 19 00 3E 4F <- a.Read data from OTP_PROG_STAT
    Recv : 00 00 05 19 01 FE 51 <- [DONE] = 1. OK.
    Send : 80 00 05 1A 00 3E BF <- b.Read data from OTP_CUST1_STAT
    Recv : 00 00 05 1A 00 3F 61 <-  [PROGOK], [TRY], [OVOK], and [UVOK] bits are not 1. Why?

    Step6
    Send : 90 00 03 09 02 93 8C <- a. Write data to CONTROL1[SOFT_RESET].


    2.Program the OTP(Page 2)

    Step1
    Send : 93 00 03 00 02 B7 78 BC 9B 6E <- a. Write data to OTP_PROG_UNLOCK1A to OTP_PROG_UNLOCK1D.
    Send : 93 00 03 52 7E 12 08 6F 4F 4C <- b. Write data to OTP_PROG_UNLOCK2A to OTP_PROG_UNLOCK2D.

    Step2
    Send : 80 00 05 19 00 3E 4F <- a. Read data from OTP_PROG_STAT
    Recv : 00 00 05 19 80 3E 31 <- [UNLOCK] = 1. OK.

    Step3
    Send : 90 00 03 0B 03 53 2C <- b. Write data to OTP_PROG_CTRL [PAGESEL][PROG_GO].

    Step4
    Wait tPROG= 100ms.

    Step5
    Send : 80 00 05 19 00 3E 4F <- a.Read data from OTP_PROG_STAT
    Recv : 00 00 05 19 01 FE 51 <- [DONE] = 1. OK.
    Send : 80 00 05 1B 00 3F 2F <- c.Read data from OTP_CUST2_STAT
    Recv : 00 00 05 1B 00 3E F1 <- [LOADED], [PROGOK], [TRY], [OVOK], and [UVOK] bits are not 1.

    Send : 90 00 03 09 02 93 8C <- a. Write data to CONTROL1[SOFT_RESET].

    ***********

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    When you reset the device do you see the information you put into the NVM registers reflected in the actual registers? Did you place the appropriate CRC bits in CUST_CRC_HI/LO before running OTP programming?

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    > When you reset the device do you see the information you put into the NVM registers reflected in the actual registers?
    Yes, I reset the device and the information looked as expected.

    > Did you place the appropriate CRC bits in CUST_CRC_HI/LO before running OTP programming?
    Yes, I set the CRC value calculated after modifying the shadow register is set.
    For reference, I am attaching a file with the shadow register I set up.

    (The value read at reset was the same.)


    Fullscreen OtpProgrammingValue.txt Download 
    Value , Addr   , Register Name     , Setting Values
01    , 0x0000 , DIR0_ADDR_OTP     , No changes.
01    , 0x0001 , DIR1_ADDR_OTP     , No changes.
54    , 0x0002 , DEV_CONF          , No changes.
06    , 0x0003 , ACTIVE_CELL       , NUM_CELL : 0x6
00    , 0x0004 , OTP_SPARE15       , -
00    , 0x0005 , BBVC_POSN1        , No changes.
00    , 0x0006 , BBVC_POSN2        , No changes.
00    , 0x0007 , ADC_CONF1         , AUX_SETTLE : 00b
00    , 0x0008 , ADC_CONF2         , No changes.
27    , 0x0009 , OV_THRESH         , OV_THR ; 0x27
20    , 0x000A , UV_THRESH         , UV_THR : 0x20
F2    , 0x000B , OTUT_THRESH       , UT_THR : 000b  OT_THR : 0x12
00    , 0x000C , UV_DISABLE1       , No changes.
00    , 0x000D , UV_DISABLE2       , No changes.
09    , 0x000E , GPIO_CONF1        , GPIO1 : 001b  GPIO2 : 001b 
09    , 0x000F , GPIO_CONF2        , GPIO3 : 001b  GPIO4 : 001b 
09    , 0x0010 , GPIO_CONF3        , GPIO5 : 001b  GPIO6 : 001b 
09    , 0x0011 , GPIO_CONF4        , GPIO7 : 001b  GPIO8 : 001b 
00    , 0x0012 , OTP_SPARE14       , -
00    , 0x0013 , OTP_SPARE13       , -
00    , 0x0014 , OTP_SPARE12       , -
00    , 0x0015 , OTP_SPARE11       , -
00    , 0x0016 , FAULT_MSK1        , No changes.
00    , 0x0017 , FAULT_MSK2        , No changes.
10    , 0x0018 , PWR_TRANSIT_CONF  , TWARN_THR : 10b
1B    , 0x0019 , COMM_TIMEOUT_CONF , CTS_TIME : 001b  CTL_ACT : 1b  CTL_TIME : 011b
00    , 0x001A , TX_HOLD_OFF       , No changes.
00    , 0x001B , MAIN_ADC_CAL1     , No changes.
00    , 0x001C , MAIN_ADC_CAL2     , No changes.
00    , 0x001D , AUX_ADC_CAL1      , No changes.
00    , 0x001E , AUX_ADC_CAL2      , No changes.
00    , 0x001F , OTP_RSVD1F        , -
00    , 0x0020 , OTP_RSVD20        , -
00    , 0x0021 , CUST_MISC1        , No changes.
00    , 0x0022 , CUST_MISC2        , No changes.
00    , 0x0023 , CUST_MISC3        , No changes.
00    , 0x0024 , CUST_MISC4        , No changes.
00    , 0x0025 , CUST_MISC5        , No changes.
00    , 0x0026 , CUST_MISC6        , No changes.
00    , 0x0027 , CUST_MISC7        , No changes.
00    , 0x0028 , CUST_MISC8        , No changes.
00    , 0x0029 , STACK_RESPONSE    , No changes.
00    , 0x002A , BBP_LOC           , No changes.
00    , 0x002B , OTP_RSVD2B        , -
00    , 0x002C , OTP_SPARE10       , -
00    , 0x002D , OTP_SPARE9        , -
00    , 0x002E , OTP_SPARE8        , -
00    , 0x002F , OTP_SPARE7        , -
00    , 0x0030 , OTP_SPARE6        , -
00    , 0x0031 , OTP_SPARE5        , -
00    , 0x0032 , OTP_SPARE4        , -
00    , 0x0033 , OTP_SPARE3        , -
00    , 0x0034 , OTP_SPARE2        , -
00    , 0x0035 , OTP_SPARE1        , -
83    , 0x0036 , CUST_CRC_HI       , The high byte of the CRC calculation.
BA    , 0x0037 , CUST_CRC_LO       , The low byte of the CRC calculation.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    If you attempt to do OTP programming on a device has already had the pages successfully programmed, you will get the results you are seeing. It seems like you have already programmed your devices.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,
    Sorry for the misleading comments.
    The shadow registers are the settings before they are saved in the NVM registers, and I performed OTP programming on a device with NVM registers not saved.
    If the device is already programmed, the OTP_CUST1_STAT[PROGOK] and [TRY] bits will be 1, but I made sure both bits were 0 before doing the OTP programming.

    No OTP Programming.
    Send : 80 00 05 1A 00 3E BF <- Read data from OTP_PROG_STAT.
    Recv : 00 00 05 1A 00 3F 61 <- [PROGOK] and [TRY] bits are 0.

    Already OTP Programming.
    Send : 80 00 05 1A 00 3E BF <- Read data from OTP_PROG_STAT.
    Recv : 00 00 05 1A 0F 7F 65 <- [PROGOK] and [TRY] bits are 1.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    On the device that is giving you 0x00 in OTP_CUST1_STAT after you attempt OTP programming (I will call this device the "failing device") the 0x00 indicates both OVOK = 0 and UVOK = 0, which means the device may have detected an OV event and an UV event during OTP programming. Having both at the same time and have it not be detected in OTP_PROG_STAT is very unlikely. 

    There are some questions I have for you:

    1) On the "failing device", when you perform a reset, do you see the registers being correctly loaded with the values you attempted to program into the OTP page? If this is successful despite the value of OTP_CUST1_STAT, the registers may be broken somehow.

    2) Can you attempt the OTP programming again on the "failing device" and measure LDION voltage a die temp during the procedure? This would tell us if the device is correctly detecting the OVOK and UVOK faults.

    3) On devices that are NOT the "failing device", can you successfully program the OTP page and it works as expected? If you can, it would tell us that the procedure is nominally correct.

    4) Do you have multiple "failing devices", in other words, multiple devices that show 0x00 in OTP_CUST1_STAT after attempting OTP programming?

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,
    I will answer questions 3) and 4).
    I'm sorry, but I'll check 1) and 2) before I answer.

    3) On devices that are NOT the "failing device", can you successfully program the OTP page and it works as expected? If you can, it would tell us that the procedure is nominally correct.
    -> No, when I try OTP programming, all devices show 0x00 in OTP_CUST1_STAT and it doesn't work as expected.


    4) Do you have multiple "failing devices", in other words, multiple devices that show 0x00 in OTP_CUST1_STAT after attempting OTP programming?

    -> Yes, any device will show 0x00 in OTP_CUST1_STAT after OTP programming is attempted.

  • 0 in reply to Yoshihiro Kato
    Prodigy 30 points

    Ben san,
    I have a few questions about 2).

    2)-1 Is it possible to measure the LDOIN voltage and die temperature on a device that has already been OTP programmed?
    2)-2 Is it okay to measure the die temperature by reading DIETEMP1_HI/LO and DIETEMP2_HI/LO before OTP programming?
    2)-3 Does the LDOIN voltage change from 6V to 8V when OTP programming starts?

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    I will answer your questions in order, but we need answers to our questions to attempt to diagnose this.

    2.1) You can always measure the LDOIN voltage, but we are only interested in the voltage during an OTP programming attempt

    2.2) Yes, you can measure the DIETEMP using the registers before and after OTP programming, but not during

    2.3) It is supposed to change to 8V when OTP programming starts as per the chart on page 13 of the datasheet:

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for waiting.
    I will answer questions 1) and 2).

    1) Yes, after resetting the device, the expected value was written to the OTP.
    I am attaching the logs for each state.

    - 1.OtpDefaultValues.txt
    -> SHUTDOWN mode to ACTIVE mode(Default values[No OTP Programming ])

    Fullscreen 1.OtpDefaultValues.txt Download 
    SHUTDOWM mode -> ACTIVE mode(Default values[No OTP Programming ])

Value , Addr   , Register Name     , Changing Values
01    , 0x0000 , DIR0_ADDR_OTP     , -
01    , 0x0001 , DIR1_ADDR_OTP     , -
54    , 0x0002 , DEV_CONF          , -
0A    , 0x0003 , ACTIVE_CELL       , -
00    , 0x0004 , OTP_SPARE15       , -
00    , 0x0005 , BBVC_POSN1        , -
00    , 0x0006 , BBVC_POSN2        , -
00    , 0x0007 , ADC_CONF1         , -
00    , 0x0008 , ADC_CONF2         , -
3F    , 0x0009 , OV_THRESH         , -
00    , 0x000A , UV_THRESH         , -
E0    , 0x000B , OTUT_THRESH       , -
00    , 0x000C , UV_DISABLE1       , -
00    , 0x000D , UV_DISABLE2       , -
00    , 0x000E , GPIO_CONF1        , -
00    , 0x000F , GPIO_CONF2        , -
00    , 0x0010 , GPIO_CONF3        , -
00    , 0x0011 , GPIO_CONF4        , -
00    , 0x0012 , OTP_SPARE14       , -
00    , 0x0013 , OTP_SPARE13       , -
00    , 0x0014 , OTP_SPARE12       , -
00    , 0x0015 , OTP_SPARE11       , -
00    , 0x0016 , FAULT_MSK1        , -
00    , 0x0017 , FAULT_MSK2        , -
10    , 0x0018 , PWR_TRANSIT_CONF  , -
00    , 0x0019 , COMM_TIMEOUT_CONF , -
00    , 0x001A , TX_HOLD_OFF       , -
00    , 0x001B , MAIN_ADC_CAL1     , -
00    , 0x001C , MAIN_ADC_CAL2     , -
00    , 0x001D , AUX_ADC_CAL1      , -
00    , 0x001E , AUX_ADC_CAL2      , -
00    , 0x001F , OTP_RSVD1F        , -
00    , 0x0020 , OTP_RSVD20        , -
00    , 0x0021 , CUST_MISC1        , -
00    , 0x0022 , CUST_MISC2        , -
00    , 0x0023 , CUST_MISC3        , -
00    , 0x0024 , CUST_MISC4        , -
00    , 0x0025 , CUST_MISC5        , -
00    , 0x0026 , CUST_MISC6        , -
00    , 0x0027 , CUST_MISC7        , -
00    , 0x0028 , CUST_MISC8        , -
00    , 0x0029 , STACK_RESPONSE    , -
00    , 0x002A , BBP_LOC           , -
00    , 0x002B , OTP_RSVD2B        , -
00    , 0x002C , OTP_SPARE10       , -
00    , 0x002D , OTP_SPARE9        , -
00    , 0x002E , OTP_SPARE8        , -
00    , 0x002F , OTP_SPARE7        , -
00    , 0x0030 , OTP_SPARE6        , -
00    , 0x0031 , OTP_SPARE5        , -
00    , 0x0032 , OTP_SPARE4        , -
00    , 0x0033 , OTP_SPARE3        , -
00    , 0x0034 , OTP_SPARE2        , -
00    , 0x0035 , OTP_SPARE1        , -
31    , 0x0036 , CUST_CRC_HI       , -
F3    , 0x0037 , CUST_CRC_LO       , -

    - 2.BeforeOtpProgramming.txt
    -> Before OTP Programming.

    Fullscreen 2.BeforeOtpProgramming.txt Download 
    Before OTP Programming.

Value , Addr   , Register Name     , Changing Values
01    , 0x0000 , DIR0_ADDR_OTP     , -
01    , 0x0001 , DIR1_ADDR_OTP     , -
54    , 0x0002 , DEV_CONF          , -
06    , 0x0003 , ACTIVE_CELL       , NUM_CELL : 0x6
00    , 0x0004 , OTP_SPARE15       , -
00    , 0x0005 , BBVC_POSN1        , -
00    , 0x0006 , BBVC_POSN2        , -
00    , 0x0007 , ADC_CONF1         , -
00    , 0x0008 , ADC_CONF2         , -
27    , 0x0009 , OV_THRESH         , OV_THR ; 0x27
20    , 0x000A , UV_THRESH         , UV_THR : 0x20
F2    , 0x000B , OTUT_THRESH       , UT_THR : 000b  OT_THR : 0x12
00    , 0x000C , UV_DISABLE1       , -
00    , 0x000D , UV_DISABLE2       , -
09    , 0x000E , GPIO_CONF1        , GPIO1 : 001b  GPIO2 : 001b
09    , 0x000F , GPIO_CONF2        , GPIO3 : 001b  GPIO4 : 001b
09    , 0x0010 , GPIO_CONF3        , GPIO5 : 001b  GPIO6 : 001b
09    , 0x0011 , GPIO_CONF4        , GPIO7 : 001b  GPIO8 : 001b
00    , 0x0012 , OTP_SPARE14       , -
00    , 0x0013 , OTP_SPARE13       , -
00    , 0x0014 , OTP_SPARE12       , -
00    , 0x0015 , OTP_SPARE11       , -
00    , 0x0016 , FAULT_MSK1        , -
00    , 0x0017 , FAULT_MSK2        , -
10    , 0x0018 , PWR_TRANSIT_CONF  , -
00    , 0x0019 , COMM_TIMEOUT_CONF , -
00    , 0x001A , TX_HOLD_OFF       , -
00    , 0x001B , MAIN_ADC_CAL1     , -
00    , 0x001C , MAIN_ADC_CAL2     , -
00    , 0x001D , AUX_ADC_CAL1      , -
00    , 0x001E , AUX_ADC_CAL2      , -
00    , 0x001F , OTP_RSVD1F        , -
00    , 0x0020 , OTP_RSVD20        , -
00    , 0x0021 , CUST_MISC1        , -
00    , 0x0022 , CUST_MISC2        , -
00    , 0x0023 , CUST_MISC3        , -
00    , 0x0024 , CUST_MISC4        , -
00    , 0x0025 , CUST_MISC5        , -
00    , 0x0026 , CUST_MISC6        , -
00    , 0x0027 , CUST_MISC7        , -
00    , 0x0028 , CUST_MISC8        , -
00    , 0x0029 , STACK_RESPONSE    , -
00    , 0x002A , BBP_LOC           , -
00    , 0x002B , OTP_RSVD2B        , -
00    , 0x002C , OTP_SPARE10       , -
00    , 0x002D , OTP_SPARE9        , -
00    , 0x002E , OTP_SPARE8        , -
00    , 0x002F , OTP_SPARE7        , -
00    , 0x0030 , OTP_SPARE6        , -
00    , 0x0031 , OTP_SPARE5        , -
00    , 0x0032 , OTP_SPARE4        , -
00    , 0x0033 , OTP_SPARE3        , -
00    , 0x0034 , OTP_SPARE2        , -
00    , 0x0035 , OTP_SPARE1        , -
C3    , 0x0036 , CUST_CRC_HI       , The high byte of the New CRC calculation.
AA    , 0x0037 , CUST_CRC_LO       , The low byte of the New CRC calculation.

    - 3.AfterOtpProgramming.txt
    -> After OTP Programming.

    Fullscreen 3.AfterOtpProgramming.txt Download 
    After OTP Programming.

Value , Addr   , Register Name     , Changing Values
01    , 0x0000 , DIR0_ADDR_OTP     , -
01    , 0x0001 , DIR1_ADDR_OTP     , -
54    , 0x0002 , DEV_CONF          , -
06    , 0x0003 , ACTIVE_CELL       , NUM_CELL : 0x6
00    , 0x0004 , OTP_SPARE15       , -
00    , 0x0005 , BBVC_POSN1        , -
00    , 0x0006 , BBVC_POSN2        , -
00    , 0x0007 , ADC_CONF1         , -
00    , 0x0008 , ADC_CONF2         , -
27    , 0x0009 , OV_THRESH         , OV_THR ; 0x27
20    , 0x000A , UV_THRESH         , UV_THR : 0x20
F2    , 0x000B , OTUT_THRESH       , UT_THR : 000b  OT_THR : 0x12
00    , 0x000C , UV_DISABLE1       , -
00    , 0x000D , UV_DISABLE2       , -
09    , 0x000E , GPIO_CONF1        , GPIO1 : 001b  GPIO2 : 001b
09    , 0x000F , GPIO_CONF2        , GPIO3 : 001b  GPIO4 : 001b
09    , 0x0010 , GPIO_CONF3        , GPIO5 : 001b  GPIO6 : 001b
09    , 0x0011 , GPIO_CONF4        , GPIO7 : 001b  GPIO8 : 001b
00    , 0x0012 , OTP_SPARE14       , -
00    , 0x0013 , OTP_SPARE13       , -
00    , 0x0014 , OTP_SPARE12       , -
00    , 0x0015 , OTP_SPARE11       , -
00    , 0x0016 , FAULT_MSK1        , -
00    , 0x0017 , FAULT_MSK2        , -
10    , 0x0018 , PWR_TRANSIT_CONF  , -
00    , 0x0019 , COMM_TIMEOUT_CONF , -
00    , 0x001A , TX_HOLD_OFF       , -
00    , 0x001B , MAIN_ADC_CAL1     , -
00    , 0x001C , MAIN_ADC_CAL2     , -
00    , 0x001D , AUX_ADC_CAL1      , -
00    , 0x001E , AUX_ADC_CAL2      , -
00    , 0x001F , OTP_RSVD1F        , -
00    , 0x0020 , OTP_RSVD20        , -
00    , 0x0021 , CUST_MISC1        , -
00    , 0x0022 , CUST_MISC2        , -
00    , 0x0023 , CUST_MISC3        , -
00    , 0x0024 , CUST_MISC4        , -
00    , 0x0025 , CUST_MISC5        , -
00    , 0x0026 , CUST_MISC6        , -
00    , 0x0027 , CUST_MISC7        , -
00    , 0x0028 , CUST_MISC8        , -
00    , 0x0029 , STACK_RESPONSE    , -
00    , 0x002A , BBP_LOC           , -
00    , 0x002B , OTP_RSVD2B        , -
00    , 0x002C , OTP_SPARE10       , -
00    , 0x002D , OTP_SPARE9        , -
00    , 0x002E , OTP_SPARE8        , -
00    , 0x002F , OTP_SPARE7        , -
00    , 0x0030 , OTP_SPARE6        , -
00    , 0x0031 , OTP_SPARE5        , -
00    , 0x0032 , OTP_SPARE4        , -
00    , 0x0033 , OTP_SPARE3        , -
00    , 0x0034 , OTP_SPARE2        , -
00    , 0x0035 , OTP_SPARE1        , -
C3    , 0x0036 , CUST_CRC_HI       , The high byte of the New CRC calculation.
AA    , 0x0037 , CUST_CRC_LO       , The low byte of the New CRC calculation.

    2) I will report the measurement results of LDOIN voltage and die temperature.
    As shown in the attached image, the LDOIN voltage changed from 6V to 8V when I started OTP programming.

    The DIETEMP1_HI/LO and DIETEMP2_HI/LO registers were between 30 and 32.8 degrees.

    Read Die Tempature 1 and 2
    Send : 80 00 05 AE 03 09 BE
    Recv : 03 00 05 AE 05 20 04 BE 6A 25

    - DIETEMP1_HI/LO
    0x520 = 1312 * 0.025 = 32.8 degrees.

    - DIETEMP2_HI/LO
    0x4BE = 1214 * 0.025 = 30.35 degrees.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    Sorry for the delayed response.

    Can you clarify if step three ("AfterOTPProgramming") in your previous reply is AFTER a digital reset? To clarify, this is the procedure we expect: 1) attempt to program the OTP registers 2) preform a digital reset (send a WAKE tone or power cycle the device) 3) read the OTP registers. If the OTP registers are the correct value then we will know the programming was successful. 

    Also, can you read all of the fault registers in addition to the OTP registers?

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for your reply.
    "3.AfterOtpProgramming.txt" is the value read after performing a digital reset with WAKE tone.
    The OTP register values ​​are correct, so I think the programming was successful, but I have a few questions.

    1. Is "1)" steps 1-6 in "Figure 9-26. Programming OTP"? If that's correct, are the following steps necessary?

    2. The register values ​​changed by OTP programming will not take effect until a digital reset is performed?

    > Also, can I read all the fault registers in addition to the OTP registers?

    Yes, I can read the fault registers, but what kind of errors could occur?

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    1) Steps 5.b and 5.c are not strictly necessary, they only confirm that OTP programming was successful. Step 6 actually updates the registers so they reflect the correct value

    2) Yes. The registers will not be populated by the OTP value until a reset is performed.

    3) We were wondering what faults, if any, you saw during the OTP process.

    Could you confirm that you are doing this on devices you have not already programmed? You can do this by checking 0x51A and 0x51B before the programming attempt.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    1) I understood that steps 5.b and 5.c are required to know if the OTP programming was successful.
        So I have a few questions:
           1. Is it necessary to wait between step 5.a and step 5.b (step 5.c)?
               If so, how long should the wait be?
           2. After performing step 6, how long should we wait for the register to update?

    3) Should I read the fault register from 0x52D to 0x554?
         Also, when should I read the fault register? (After step 5 or after step 6?)

    > You can do this by checking 0x51A and 0x51B before the programming attempt.
     Before attempting to program Page 1, we check that 0x51A(OTP_CUST1_STAT) meets the following conditions.

     

    For reference, I have attached the command log for programming Page 1.

    Fullscreen OtpProgrammingCommands.txt Download 
    Before programming the OTP, host ensures:
  A valid page is one with OTP_CUST1_STAT1[TRY] = 0 and OTP_CUST1_STAT1[FMTERR] = 0.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 00 3F 61

Program the OTP.
Step1.
Send : 93 00 03 00 02 B7 78 BC 9B 6E
Send : 93 00 03 52 7E 12 08 6F 4F 4C

Step2.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 80 3E 31

Step3 a.
Send : 90 00 03 0B 01 D2 ED

Step4.
Wait tPROG= 100ms.

Step5 a.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 01 FE 51

Step5 b.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 00 3F 61

Step6.
Send : 90 00 03 09 02 93 8C

    Best regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    You do not need to wait between step 5.a and 5.b. You need to wait 1 ms after step 6 for the soft reset to complete.

    The fault registers could be read before the process, after step five, and after step six. You also need to read both 0x51a and 0x51b, as the pages may be related to each other.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    I read the fault registers so I am attaching the logs .
    As a result, no faults occurred.

    Fullscreen FaultRegisters_20240614.txt Download 
    Addr,   Fault Registers,        Before Process, After Step 5,   After Step 6

0x52D,  FAULT_SUMMARY,          00,             00,             00,
0x52E,  -,                      00,             00,             00,
0x52F   -,                      00,             00,             00,
0x530,  FAULT_COMM1             00,             00,             00,
0x531   FAULT_COMM2,            00,             00,             00,
0x532   FAULT_COMM3,            00,             00,             00,
0x533   -,                      00,             00,             00,
0x534   -,                      00,             00,             00,
0x535   FAULT_OTP,              00,             00,             00,
0x536   FAULT_SYS,              00,             00,             00,
0x537   -,                      00,             00,             00,
0x538   -,                      00,             00,             00,
0x539   -,                      00,             00,             00,
0x53A   FAULT_PROT1,            00,             00,             00,
0x53B   FAULT_PROT2,            00,             00,             00,
0x53C   FAULT_OV1,              00,             00,             00,
0x53D   FAULT_OV2,              00,             00,             00,
0x53E   FAULT_UV1,              00,             00,             00,
0x53F   FAULT_UV2,              00,             00,             00,
0x540   FAULT_OT.               00,             00,             00,
0x541   FAULT_UT,               00,             00,             00,
0x542   -,                      00,             00,             00,
0x543   FAULT_COMP_GPIO,        00,             00,             00,
0x544   -,                      00,             00,             00,
0x545   FAULT_COMP_VCCB1,       00,             00,             00,
0x546   FAULT_COMP_VCCB2,       00,             00,             00,
0x547   -,                      00,             00,             00,
0x548   FAULT_COMP_VCOW1,       00,             00,             00,
0x549   FAULT_COMP_VCOW2,       00,             00,             00,
0x54A   -,                      00,             00,             00,
0x54B   FAULT_COMP_CBOW1,       00,             00,             00,
0x54C   FAULT_COMP_CBOW2,       00,             00,             00,
0x54D   -,                      00,             00,             00,
0x54E   FAULT_COMP_CBFET1,      00,             00,             00,
0x54F   FAULT_COMP_CBFET2,      00,             00,             00,
0x550   FAULT_COMP_MISC,        00,             00,             00,
0x551   -,                      00,             00,             00,
0x552   FAULT_PWR1,             00,             00,             00,
0x553   FAULT_PWR2,             00,             00,             00,
0x554   FAULT_PWR3,             00,             00,             00,

    By the way, after step 6, 0x51A and 0x51B could not be read.
    What could be the reason for this?
    (See OtpProgrammingCommands20240614.txt for details)

    Fullscreen OtpProgrammingCommands20240614.txt Download 
    (Read Fault Registers[Before Process])

Before programming the OTP, host ensures:
  OTP_CUST1_STAT1[LODED],[PROGOK],[UVOK],{OVOK} and [TRY] = 1.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 8F 7E C5

  OTP_CUST2_STAT1[TRY] = 0 and OTP_CUST1_STAT2[FMTERR] = 0.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 00 05 1B 00 3E F1

Program the OTP.
Step1.
Send : 93 00 03 00 02 B7 78 BC 9B 6E
Send : 93 00 03 52 7E 12 08 6F 4F 4C

Step2.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 80 3E 31

Step3 a.(Page2)
Send : 90 00 03 0B 03 53 2C

Step4.
Wait tPROG = 100ms.

Step5 a.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 01 FE 51

Step5 b.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 00 05 1B 00 3E F1

(Read Fault Registers[After Step 5])

Step6.
Send : 90 00 03 09 02 93 8C

Wait tRST = 1ms.

(Read Fault Registers[After Step 6])

Read OTP_CUST1_STAT1 again,
Send : 80 00 05 1A 00 3E BF
Recv : 00 F1 AD F0 00 00 20 <- No response from the device?

Read OTP_CUST1_STAT2 again,
Send : 80 00 05 1B 00 3F 2F
Recv : 00 F1 AD F0 00 00 20 <- No response from the device?

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    After step 6 you need to autoaddress the device before you can read from it again.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    I did autoaddress the device after step 6,so is the following steps correct?

    1.Send broadcast write to set CONTROL1[ADDR_WR] = 1.
      Send : D0 03 09 01 0F 74

    2.Send broadcast write to DIR0_ADDR register with data 0x00.
      Send : D0 03 06 00 CB 44

    3.Send broadcast write to set COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 0, and CONTROL1[ADDR_WR] = 0.
      Send : 91 00 03 08 00 00 9D 1C

    Best regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    For the auto-address sequence, if you only have one device it needs to have COMM_CTRL = 0x01 and the ADDR_WR bit is self-clearing, there is no need to reset it. Otherwise, it should be okay. 

    I have talked to the designers of the BQ79616 and have learned a few things:

    1) The two programming pages are there in case the programming of page one fails. If you program both pages, page one will never be loaded. The correct procedure is to program page one, and if (and only if) that fails program page two. If bad data is detected when attempting to load the OTP page, the HW reset values will be placed in place of the bad data. 

    2) You cannot program page one after you program page two.

    3) 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.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for your advice.
    There is only one device to implement.
    So we need to set COMM_CTRL = 0x01, and CONTROL1 doesn't need to be set, right?

     

    1) If we set a value in the shadow register, we can use the device without OTP programming, but in what cases should we need OTP programming?

    3) After step 4, should I follow the steps below?
      Step5
       Check to ensure there is no error during OTP programming. The following bits are expected to be 1 after a successful OTP programming:
       a. OTP_PROG_STAT[DONE] = 1, OTP programming is done. No other bit will be set in this register.

    Step6
       Issue a digital reset to reload the registers with the updated OTP values:
       a. CONTROL1[SOFT_RESET] = 1

     Step7
       Wait tRST = 1msec. for the soft reset to complete.

     Step8
       Setting Up Auto-Addressing.
       a.CONTROL1[ADDR_WR] = 1.
       b.DIR0_ADDR = 0x00.(for example)
       c.COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.

      *** Need to wait until the ADDR_WR bit is cleared before Step 9? ***

     Step9

       Check to confirm the OTP programming was successful:
       a. If page 1 is programmed, OTP_CUST1_STAT[LOADED], [PROGOK], [TRY], [OVOK], and [UVOK] bits are 1. Other bits are 0.
       b. If page 2 is programmed, OTP_CUST2_STAT[LOADED], [PROGOK], [TRY], [OVOK], and [UVOK] bits are 1. Other bits are 0.


    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    OTP Programming is useful when you have configurations in a device that you know before you wake them. Common examples include the device id and adc settings. Whenever the device receives a digital reset you will get the values loaded in the OTP pages instead of the default values and you do not have to program them every time you perform this reset. This is most common with the device id because you must perform auto-addressing to configure the device id and the entire process can be skipped if the stack is correctly configured ahead of time. 

    After you send a command that sets ADDR_WR, the next write command that the device receives clears ADDR_WR. When ADDR_WR is set the device does not forward commands, so a broadcast write will stop at that device. Additionally, having ADDR_WR set is the only time you can write to the DIR0/1_ADDR registers. If you follow the steps of the auto-addressing procedure, you will not have to wait any additional time before you go to step nine.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for your comment.
    I try to OTP programming with the steps we have reviewed.

    Let me check one more thing just in case.
    If I don't set COMM_CTRL[TOP_STACK] to 1 in Step 8, will the register read in Step 9 fail as shown below?

    Read OTP_CUST1_STAT1 again,
    Send : 80 00 05 1A 00 3E BF
    Recv : 00 F1 AD F0 00 00 20 <- No response from the device?

    Read OTP_CUST1_STAT2 again,
    Send : 80 00 05 1B 00 3F 2F
    Recv : 00 F1 AD F0 00 00 20 <- No response from the device?


    Best regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    Yes. If you do not correctly complete the auto-addressing sequence in totality, the device will not support reads as per section 9.3.6.1.3 of the datasheet. Only broadcast writes are supported before auto-addressing is completed. 

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for your reply.
    I performed OTP programming on page 1 and confirmed that it worked as expected.
    (See OtpProgramming_Page1.txt for details)

    Fullscreen 8424.OtpProgramming_Page1.txt Download 
    Before programming the OTP, host ensures:
  OTP_CUST1_STAT1[TRY] = 0 and OTP_CUST1_STAT2[FMTERR] = 0.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 00 3F 61

  OTP_CUST2_STAT1[TRY] = 0 and OTP_CUST2_STAT2[FMTERR] = 0.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 00 05 1B 00 3E F1

Program the OTP.
Step1.
Send : 93 00 03 00 02 B7 78 BC 9B 6E
Send : 93 00 03 52 7E 12 08 6F 4F 4C

Step2.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 80 3E 31

Step3 a.(Page1)
Send : 90 00 03 0B 01 D2 ED

Step4.
Wait tPROG = 100ms.

Step5 a.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 01 FE 51

Step5 b.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 00 3F 61

Step6.
Send : 90 00 03 09 02 93 8C

Step7
Wait tRST = 1ms.

Step8 a.
Send : D0 03 09 01 0F 74

Step8 b.
Send : D0 03 06 00 CB 44

Step8 c.
Send : 90 00 03 08 01 D2 1D <- COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.

Step9 a.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 8F 7E C5 <- Read Successful!!

Step9 b.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 00 05 1B 00 3E F1 <- Read Successful!!

    However, when I then performed OTP programming on page 2, there was no response from the device in step 9.
    (See OtpProgramming_Page2.txt for details)
    If I write to page 2, should I not perform "a." in step 9?

    Fullscreen 2148.OtpProgramming_Page2.txt Download 
    Before programming the OTP, host ensures:
  OTP_CUST1_STAT1[LOADED],[PROGOK],[UVOK],{OVOK} and [TRY] = 1.
Send : 80 00 05 1A 00 3E BF
Recv : 00 00 05 1A 8F 7E C5

  OTP_CUST2_STAT1[TRY] = 0 and OTP_CUST2_STAT2[FMTERR] = 0.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 00 05 1B 00 3E F1

Program the OTP.
Step1.
Send : 93 00 03 00 02 B7 78 BC 9B 6E
Send : 93 00 03 52 7E 12 08 6F 4F 4C

Step2.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 80 3E 31

Step3 a.(Page2)
Send : 90 00 03 0B 03 53 2C

Step4.
Wait tPROG = 100ms.

Step5 a.
Send : 80 00 05 19 00 3E 4F
Recv : 00 00 05 19 01 FE 51

Step5 c.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 00 05 1B 00 3E F1

Step6.
Send : 90 00 03 09 02 93 8C

Step7
Wait tRST = 1ms.

Step8 a.
Send : D0 03 09 01 0F 74

Step8 b.
Send : D0 03 06 00 CB 44

Step8 c.
Send : 90 00 03 08 01 D2 1D <- COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.

Step9 a.
Send : 80 00 05 1A 00 3E BF
Recv : 00 F0 00 00 20 43 06 <- No response from the device?

Step9 b.
Send : 80 00 05 1B 00 3F 2F
Recv : 00 F0 00 00 20 43 06 <- No response from the device?

    Also, as a separate question, will NFAULT occur if I perform step 6?


    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    Yes, performing a digital reset (which is what you are doing in step 6) will cause FAULT_SYS[DRST] = 1. 

    It is possible that you need to do the complete auto-addressing sequence (including steps 1 and 5, synchronizing DLL) each time for the devices to work reliably. Please find those steps in section 9.3.6.1.3.2.2 in the datasheet (link).

    Additionally, you do not need to program both pages on a single device if the programming of page 1 is successful. I have learned that the two pages are NOT redundant and if page 2 is programmed, page 1 will never be read. Page 2 is there only needed if the programming of page 1 is unsuccessful.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thanks for your advice.
    I will ignore NFAULT after digital reset in step 6.

    I hadn't considered synchronizing DLL.
    For step 8, what are the specific steps I should follow?

    (Steps in red font are added)

    1.Dummy Write to synchronize all daisy chain devices DLL ramp in write direction.

      Broadcast write OTP_ECC_DATAIN1 through OTP_ECC_DATAIN9 = 0x00(for example).

    2.Setting Up Auto-Addressing.
      a.CONTROL1[ADDR_WR] = 1.
      b.DIR0_ADDR = 0x00.(for example)
      c.COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.

    3.Dummy read to synchronize all daisy chain devices DLL ramp in read direction.
      Broadcast read to read OTP_ECC_DATAOUT1 through OTP_ECC_DATAOUT9.

    Also, after performing all the steps, do I need to wait to read the device?
    Or can I just repeat the steps until the OTP_ECC_DATAOUT1-9 read is successful?

    Best regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    The two steps in red are correct. You need to broadcast write 0x00 to OTP_ECC_DATAIN1 through OTP_ECC_DATAIN9 and then broadcast read to the same registers afterwards. These need to be eight separate writes/reads and they must be done one after another. You will not receive any data from the reads.

    You do not have to wait before or after the commands.

    Regards,

    Ben 

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Before doing OTP programming, I tried to auto-addressing after transitioning from SHUTDOWN to ACTIVE mode.
    As a result, dummy reading after OTP_ECC_DATAOUT3 is not possible.
    (See Auto-Addressing.txt for details)

    Fullscreen Auto-Addressing.txt Download 
    1.Dummy Write to synchronize all daisy chain devices DLL ramp in write direction.
  Broadcast write OTP_ECC_DATAIN1 through OTP_ECC_DATAIN9 = 0x00.
        Send : D0 03 43 00 F9 D4  <- OTP_ECC_DATAIN1
        Send : D0 03 44 00 FB E4  <- OTP_ECC_DATAIN2
        Send : D0 03 45 00 FA 74  <- OTP_ECC_DATAIN3
        Send : D0 03 46 00 FA 84  <- OTP_ECC_DATAIN4
        Send : D0 03 47 00 FB 14  <- OTP_ECC_DATAIN5
        Send : D0 03 48 00 FE E4  <- OTP_ECC_DATAIN6
        Send : D0 03 49 00 FF 74  <- OTP_ECC_DATAIN7
        Send : D0 03 4A 00 FF 84  <- OTP_ECC_DATAIN8
        Send : D0 03 4B 00 FE 14  <- OTP_ECC_DATAIN9

2.Setting Up Auto-Addressing.
  a.CONTROL1[ADDR_WR] = 1.
        Send : D0 03 09 01 0F 74
  b.DIR0_ADDR = 0x00.
        Send : D0 03 06 00 CB 44
  c.COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.
        Send : 90 00 03 08 01 D2 1D

3.Dummy read to synchronize all daisy chain devices DLL ramp in read direction.
  Broadcast read to read OTP_ECC_DATAOUT1 through OTP_ECC_DATAOUT9.
        Send : C0 05 10 00 21 E5  <- OTP_ECC_DATAOUT1
        Recv : 00 00 05 10 00 39  -> Dummy Data?
        Send : C0 05 11 00 20 75  <- OTP_ECC_DATAOUT2
        Recv : C1 00 00 05 11 00  -> Dummy Data?
        Send : C0 05 12 00 20 85  <- OTP_ECC_DATAOUT3
        Recv : No Response.
        Send : C0 05 13 00 21 15  <- OTP_ECC_DATAOUT4
        Recv : No Response.
        Send : C0 05 14 00 23 25  <- OTP_ECC_DATAOUT5
        Recv : No Response.
        Send : C0 05 15 00 22 B5  <- OTP_ECC_DATAOUT6
        Recv : No Response.
        Send : C0 05 16 00 22 45  <- OTP_ECC_DATAOUT7
        Recv : No Response.
        Send : C0 05 17 00 23 D5  <- OTP_ECC_DATAOUT8
        Recv : No Response.
        Send : C0 05 18 00 26 25  <- OTP_ECC_DATAOUT9
        Recv : No Response.

- Do Fault Reset
        Send : 91 00 03 31 FF 7F 4D 01 <- FAULT_RST1 and FAULT_RST2

- Read Shadow Registers
        Send : 80 00 00 00 37 64  <- DIR0_ADDR_OTP
        Recv : No Response.

    Does "Not receive any data from the reads." mean that there is no response from the device, or that there is a response but without valid data?

    Best regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/Communication_5F00_with_5F00_one_5F00_616.sal

    I have attached a logic analyzer file showing the auto-addressing sequence (it is the first set of commands after the wake ping). You should get a response from the device, but the data will be only zeroes. 

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Thank you very much for providing the log.
    After checking the log differences, I found a bug that the dummy read size was 1 byte short.
    Fixed a bug so that a dummy read followed by a register read works as expected.

    (See the attached log for details.)

    There were also some other differences, which were corrected as follows:
    1. In Step 1, OTP_ECC_DATAIN9 was written.
    2. The "1." in Step 4 was missing.
    3. In Step 5, OTP_ECC_DATAOUT1 to OTP_ECC_DATAOUT9 were read.

    Fullscreen 7610.Auto-Addressing_20240627.txt Download 
    Table 9-19. Auto-Addressing
Step1.
  Dummy Write to synchronize all daisy chain devices DLL (delay-locked loop) ramp in write direction.
  Host sends broadcast write to write 0x00 to ECC_DATA1 to ECC_DATA8 registers.
        Send : D0 03 43 00 F9 D4  <- OTP_ECC_DATAIN1
        Send : D0 03 44 00 FB E4  <- OTP_ECC_DATAIN2
        Send : D0 03 45 00 FA 74  <- OTP_ECC_DATAIN3
        Send : D0 03 46 00 FA 84  <- OTP_ECC_DATAIN4
        Send : D0 03 47 00 FB 14  <- OTP_ECC_DATAIN5
        Send : D0 03 48 00 FE E4  <- OTP_ECC_DATAIN6
        Send : D0 03 49 00 FF 74  <- OTP_ECC_DATAIN7
        Send : D0 03 4A 00 FF 84  <- OTP_ECC_DATAIN8

Step2.
  Enable auto-addressing procedure.
  Host sends broadcast write to set CONTROL1[ADDR_WR] = 1.
        Send : D0 03 09 01 0F 74

Step3.
  Sending in the device addresses. Host sends broadcast write to set the consecutive addresses to DIR0_ADDR[ADDRESS5:0]. 
        Send : D0 03 06 00 CB 44

Step4.
  1. Host sends broadcast write to set [STACK_DEV] = 1 and [TOP_STACK] = 0.
        Send : D0 03 08 02 4E E5

  2. Host sends single device write to base device (device address 0x00 in this example) with [STACK_DEV] = 0.
  3. Host send single device write to the ToS device address 0x02 in this example) with [TOP_STACK] = 1.
        Send : 90 00 03 08 01 D2 1D

Step5.
  Dummy read to synchronize all daisy chain devices DLL ramp in read direction.
  Host sends broadcast read to read ECC_DATA1 to ECC_DATA8registers.
        Send : C0 03 43 00 FD 14    <- OTP_ECC_DATAIN1
        Recv : 00 00 03 43 00 E5 30 -> Dummy Data
        Send : C0 03 44 00 FF 24    <- OTP_ECC_DATAIN2
        Recv : 00 00 03 44 00 E7 00 -> Dummy Data
        Send : C0 03 45 00 FE B4    <- OTP_ECC_DATAIN3
        Recv : 00 00 03 45 00 E6 90 -> Dummy Data
        Send : C0 03 46 00 FE 44    <- OTP_ECC_DATAIN4
        Recv : 00 00 03 46 00 E6 60 -> Dummy Data
        Send : C0 03 47 00 FF D4    <- OTP_ECC_DATAIN5
        Recv : 00 00 03 47 00 E7 F0 -> Dummy Data
        Send : C0 03 48 00 FA 24    <- OTP_ECC_DATAIN6
        Recv : 00 00 03 48 00 E2 00 -> Dummy Data
        Send : C0 03 49 00 FB B4    <- OTP_ECC_DATAIN7
        Recv : 00 00 03 49 00 E3 90 -> Dummy Data
        Send : C0 03 4A 00 FB 44    <- OTP_ECC_DATAIN8
        Recv : 00 00 03 4A 00 E3 60 -> Dummy Data

- Do Fault Reset
        Send : 91 00 03 31 FF 7F 4D 01 <- FAULT_RST1 and FAULT_RST2

- Read Shadow Registers
        Send : 80 00 00 00 37 64 08   <- DIR0_ADDR_OTP
        Recv : 37 00 00 00 01 01 54 06 00 00 00 00 00 27 20 F2   <- DIR0_ADDR_OTP to CUST_CRC_LO
               00 00 09 09 09 09 00 00 00 00 00 00 1B 00 00 00
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
               00 00 00 00 00 00 00 00 00 00 CE 5A

    If there are no problems with the attached log, try OTP programming again.

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    That auto-addressing sequence looks correct. Once you are able to read from the device you know the sequence has worked.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    After correcting the auto-addressing, I tried the OTP programming again,
    but the result was the same - there was no response from the device when I reset after programming page 2.
    (See attached log for details)

    After programming page 2, the broadcast read fails, so there seems to be some problem other than the Auto-addressing.

    Fullscreen OTP_Programming_Page1_20240628.txt Download 
    Read OTP initial value
        Send : 80 00 00 00 37 64 08
        Recv : 37 00 00 00 01 01 54 0A 00 00 00 00 00 3F 00 E0
               00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
               00 00 00 00 00 00 00 00 00 00 31 F3

   ( Read CUST_CRC_RSLT_HI/LO for CRC check )
        Send : 80 00 05 0C 01 F1 1F
        Recv : 01 00 05 0C 31 F3 94 D0

Before programming the OTP, host ensures:
  All OTP shadow registers have the correct settings
        Send : 80 00 00 00 37 64 08
        Recv : 37 00 00 00 01 01 54 06 00 00 00 00 00 27 20 F2
               00 00 09 09 09 09 00 00 00 00 00 00 10 00 00 00
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
               00 00 00 00 00 00 00 00 00 00 C3 AA

   ( Read CUST_CRC_RSLT_HI/LO for CRC check )
        Send : 80 00 05 0C 01 F1 1F
        Recv : 01 00 05 0C C3 AA 11 8A

  OTP_CUST1_STAT1[TRY] = 0 and OTP_CUST1_STAT2[FMTERR] = 0.
        Send : 80 00 05 1A 00 3E BF
        Recv : 00 00 05 1A 00 3F 61

Table 9-26. Program the OTP
Step1.
  Unlock the OTP programming:
     a. Write the following data to OTP_PROG_UNLOCK1A to OTP_PROG_UNLOCK1D registers.
        Send : 93 00 03 00 02 B7 78 BC 9B 6E
     b. Do another write with the following data to OTP_PROG_UNLOCK2A to OTP_PROG_UNLOCK2D registers.
        Send : 93 00 03 52 7E 12 08 6F 4F 4C

Step2.
  Check to confirm the OTP unlock procedure is successful:
     a. Read to confirm OTP_PROG_STAT[UNLOCK] = 1
        Send : 80 00 05 19 00 3E 4F
        Recv : 00 00 05 19 80 3E 31

Step3.
  Select the proper OTP page and start the OTP programming:
     a. To program page1, set OTP_PROG_CTRL[PAGESEL][PROG_GO] = 0x01
        Send : 90 00 03 0B 01 D2 ED

Step4.
Wait tPROG = 100ms.

Step5.
  Check to ensure there is no error during OTP programming. The following bits are expected to be 1 after a successful OTP programming:
     a. OTP_PROG_STAT[DONE] = 1, OTP programming is done. No other bit will be set in this register.
        Send : 80 00 05 19 00 3E 4F
        Recv : 00 00 05 19 01 FE 51

Step6.
  Issue a digital reset to reload the registers with the updated OTP values:
     a. CONTROL1[SOFT_RESET] = 1
        Send : 90 00 03 09 02 93 8C

Step7.
   Wait tRST = 1msec. for the soft reset to complete.

Step8.
  Setting Up Auto-Addressing.
     a.Dummy Write to ECC_DATA1 to ECC_DATA8
        Send : D0 03 43 00 F9 D4  <- OTP_ECC_DATAIN1
        Send : D0 03 44 00 FB E4  <- OTP_ECC_DATAIN2
        Send : D0 03 45 00 FA 74  <- OTP_ECC_DATAIN3
        Send : D0 03 46 00 FA 84  <- OTP_ECC_DATAIN4
        Send : D0 03 47 00 FB 14  <- OTP_ECC_DATAIN5
        Send : D0 03 48 00 FE E4  <- OTP_ECC_DATAIN6
        Send : D0 03 49 00 FF 74  <- OTP_ECC_DATAIN7
        Send : D0 03 4A 00 FF 84  <- OTP_ECC_DATAIN8

     b.CONTROL1[ADDR_WR] = 1.
        Send : D0 03 09 01 0F 74

     c.DIR0_ADDR = 0x00.
        Send : D0 03 06 00 CB 44

     d.COMM_CTRL[STACK_DEV] = 1, COMM_CTRL[TOP_STACK] = 0.(Set with broadcast write)
        Send : D0 03 08 02 4E E5

     e.COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.(Set with single device write)
        Send : 90 00 03 08 01 D2 1D

     f.Dummy Read from ECC_DATA1 to ECC_DATA8
        Send : C0 03 43 00 FD 14    <- OTP_ECC_DATAIN1
        Recv : 00 00 03 43 00 E5 30 -> Dummy Data
        Send : C0 03 44 00 FF 24    <- OTP_ECC_DATAIN2
        Recv : 00 00 03 44 00 E7    -> Dummy Data
        Send : C0 03 45 00 FE B4    <- OTP_ECC_DATAIN3
        Recv : 00 00 03 45 00 E6 90 -> Dummy Data
        Send : C0 03 46 00 FE 44    <- OTP_ECC_DATAIN4
        Recv : 00 00 03 46 00 E6 60 -> Dummy Data
        Send : C0 03 47 00 FF D4    <- OTP_ECC_DATAIN5
        Recv : 00 00 03 47 00 E7 F0 -> Dummy Data
        Send : C0 03 48 00 FA 24    <- OTP_ECC_DATAIN6
        Recv : 00 00 03 48 00 E2 00 -> Dummy Data
        Send : C0 03 49 00 FB B4    <- OTP_ECC_DATAIN7
        Recv : 00 00 03 49 00 E3 90 -> Dummy Data
        Send : C0 03 4A 00 FB 44    <- OTP_ECC_DATAIN8
        Recv : 00 00 03 4A 00 E3 00 -> Dummy Data

Step9.
  Do Fault Reset
     a. FAULT_RST1 = 0xFF, FAULT_RST2 = 0x7F
        Send : 91 00 03 31 FF 7F 4D 01

Step10.
  Check to confirm the OTP programming was successful:
     a. OTP_CUST1_STAT[LOADED], [PROGOK], [TRY], [OVOK], and [UVOK] bits are 1.
        Other bits are 0.
        Send : 80 00 05 1A 00 3E BF
        Recv : 00 00 05 1A 8F 7E C5

- Read Updated OTP value
        Send : 80 00 00 00 37 64 08
        Recv : 37 00 00 00 01 01 54 06 00 00 00 00 00 27 20 F2
               00 00 09 09 09 09 00 00 00 00 00 00 10 00 00 00
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
               00 00 00 00 00 00 00 00 00 00 C3 AA

    Fullscreen OTP_Programming_Page2_20240628.txt Download 
    (Write the same value as the OTP for page 1)

Before programming the OTP, host ensures:
  All OTP shadow registers have the correct settings
        Send : 80 00 00 00 37 64 08
        Recv : 37 00 00 00 01 01 54 06 00 00 00 00 00 27 20 F2
               00 00 09 09 09 09 00 00 00 00 00 00 10 00 00 00
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
               00 00 00 00 00 00 00 00 00 00 C3 AA

   ( Read CUST_CRC_RSLT_HI/LO for CRC check )
        Send : 80 00 05 0C 01 F1 1F
        Recv : 01 00 05 0C C3 AA 11 8A

  OTP_CUST2_STAT1[TRY] = 0 and OTP_CUST2_STAT2[FMTERR] = 0.
        Send : 80 00 05 1B 00 3F 2F
        Recv : 00 00 05 1B 00 3E F1

Table 9-26. Program the OTP
Step1.
  Unlock the OTP programming:
     a. Write the following data to OTP_PROG_UNLOCK1A to OTP_PROG_UNLOCK1D registers.
        Send : 93 00 03 00 02 B7 78 BC 9B 6E
     b. Do another write with the following data to OTP_PROG_UNLOCK2A to OTP_PROG_UNLOCK2D registers.
        Send : 93 00 03 52 7E 12 08 6F 4F 4C

Step2.
  Check to confirm the OTP unlock procedure is successful:
     a. Read to confirm OTP_PROG_STAT[UNLOCK] = 1
        Send : 80 00 05 19 00 3E 4F
        Recv : 00 00 05 19 80 3E 31

Step3.
  Select the proper OTP page and start the OTP programming:
     b. To program page2, set OTP_PROG_CTRL[PAGESEL][PROG_GO] = 0x03
        Send : 90 00 03 0B 03 53 2C

Step4.
Wait tPROG = 100ms.

Step5.
  Check to ensure there is no error during OTP programming. The following bits are expected to be 1 after a successful OTP programming:
     a. OTP_PROG_STAT[DONE] = 1, OTP programming is done. No other bit will be set in this register.
        Send : 80 00 05 19 00 3E 4F
        Recv : 00 00 05 19 01 FE 51

Step6.
  Issue a digital reset to reload the registers with the updated OTP values:
     a. CONTROL1[SOFT_RESET] = 1
        Send : 90 00 03 09 02 93 8C

Step7.
   Wait tRST = 1msec. for the soft reset to complete.

Step8.
  Setting Up Auto-Addressing.
     a.Dummy Write to ECC_DATA1 to ECC_DATA8
        Send : D0 03 43 00 F9 D4  <- OTP_ECC_DATAIN1
        Send : D0 03 44 00 FB E4  <- OTP_ECC_DATAIN2
        Send : D0 03 45 00 FA 74  <- OTP_ECC_DATAIN3
        Send : D0 03 46 00 FA 84  <- OTP_ECC_DATAIN4
        Send : D0 03 47 00 FB 14  <- OTP_ECC_DATAIN5
        Send : D0 03 48 00 FE E4  <- OTP_ECC_DATAIN6
        Send : D0 03 49 00 FF 74  <- OTP_ECC_DATAIN7
        Send : D0 03 4A 00 FF 84  <- OTP_ECC_DATAIN8

     b.CONTROL1[ADDR_WR] = 1.
        Send : D0 03 09 01 0F 74

     c.DIR0_ADDR = 0x00.
        Send : D0 03 06 00 CB 44

     d.COMM_CTRL[STACK_DEV] = 1, COMM_CTRL[TOP_STACK] = 0.(Set with broadcast write)
        Send : D0 03 08 02 4E E5

     e.COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.(Set with single device write)
        Send : 90 00 03 08 01 D2 1D

     f.Dummy Read from ECC_DATA1 to ECC_DATA8
        Send : C0 03 43 00 FD 14    <- OTP_ECC_DATAIN1
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 44 00 FF 24    <- OTP_ECC_DATAIN2
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 45 00 FE B4    <- OTP_ECC_DATAIN3
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 46 00 FE 44    <- OTP_ECC_DATAIN4
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 47 00 FF D4    <- OTP_ECC_DATAIN5
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 48 00 FA 24    <- OTP_ECC_DATAIN6
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 49 00 FB B4    <- OTP_ECC_DATAIN7
        Recv : 00 00 00 00 00 00 00 -> No Response
        Send : C0 03 4A 00 FB 44    <- OTP_ECC_DATAIN8
        Recv : 00 00 00 00 00 00 00 -> No Response

Step9.
  Do Fault Reset
     a. FAULT_RST1 = 0xFF, FAULT_RST2 = 0x7F
        Send : 91 00 03 31 FF 7F 4D 01

Step10.
  Check to confirm the OTP programming was successful:
     b. OTP_CUST2_STAT[LOADED], [PROGOK], [TRY], [OVOK], and [UVOK] bits are 1.
        Other bits are 0.
        Send : 80 00 05 1B 00 3F 2F
        Recv : 00 F0 00 00 26 43 07 -> No Response

- Read Updated OTP value
        Send : 80 00 00 00 37 64 08
        Recv : 00 43 80 00 05 1B 00 3F 2F 43 67 F1 00 00 6C 43  -> No Response
               01 00 07 00 7C 43 07 00 03 45 01 00 8A 43 94 2E
               07 00 7C 43 07 00 00 00 01 FC 01 00 01 00 00 00
               98 43 00 00 00 00 AC 43 05 00 9A 43

    Best regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro, 

    If programming to page 1 is successful, you should not have to program page 2. 

    Are you using a separate device for the attempt at programming page 2? Could you try to send a WAKE ping instead of the soft reset in step six (and then waiting 10 ms in step 7)? Does the auto-addressing sequence normally work with the device you used for the programming of the second page?

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    > Are you using a separate device for the attempt at programming page 2?
    No, I programmed page 1 and then page 2 on the same device.

    I'm sorry I can't explain it well, but I'm trying to confirm that OTP programming to page 2 can be performed successfully if OTP programming to page 1 fails.
    In that case, should I use a device that is not programmed on either page 1 or 2?


    Best Regards.

  • 0 in reply to Yoshihiro Kato
    Prodigy 30 points

    Ben san,

    I haven't received a reply in a few days, how is the situation now?

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    I am sorry for the delay. I was out of office due to a public holiday. 

    It is odd that you are receiving garbled data, which is different than receiving nothing at all. We noticed that a command you sent reappeared in the data you received:

    This should not happen. Are you using custom code? Could you double check that the code is working as expected at this time?

    Additionally, are you doing the page 2 programming immediately after finishing the steps of the page 1 programming? You could try resetting the devices between the steps if not. 

    Finally, to double check, do you only have one BQ79616 connected in the stack?

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Sorry for the late reply.

    > Are you using custom code? Could you double check that the code is working as expected at this time?
    Yes, we use our own original source code.
    The receive buffer was not cleared before receiving the response from the device, resulting in meaningless data.

    > Additionally, are you doing the page 2 programming immediately after finishing the steps of the page 1 programming?
    No, the program is restarted after the programming procedure on page 1 is completed.
    After the program is restarted, a digital reset is performed using the WAKE signal to transition the device from shutdown mode to active mode.

    > Finally, to double check, do you only have one BQ79616 connected in the stack?
    Yes, there is no daisy chaining, just one device.

    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    Yoshihiro Kato said:
    The receive buffer was not cleared before receiving the response from the device, resulting in meaningless data.

    Hopefully fixing this bug fixes the error you were seeing in the page 2 programming.

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    Before receiving a response from the device, clear the receive buffer to 0 and perform OTP programming again.
    However, since we already know that the response cannot be received from the device, I think that fixing this bug will only change garbage data to 0, so there may be other causes.

    Best Regards.

    P.S : I will be out of office from July 12th to July 15th due to public holidays.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro, 

    In the device that you have successfully programed page one but had trouble programming page two, can you communicate with the device? In other words, what happens when you send a wake ping and auto address the device? Can you read data from it? Or is it now broken? If you can read data, what does it say about OTP programming?

    Regards,

    Ben

  • 0 in reply to Benjamin Luty
    Prodigy 30 points

    Ben san,

    On devices that have issues with page 2 programming, it is possible to read data by sending a wake ping and auto-addressing, and reading the OTP_CUST*_STAT and shadow registers shows the expected data.
    So after writing the OTP on page 2, it doesn't seem to work properly after the soft reset.

    Fullscreen WakePing_AutoAddress_ReadOTP.txt Download 
    1.Issue a digital reset by WAKE ping.

2.Setting Up Auto-Addressing.
     a.Dummy Write to ECC_DATA1 to ECC_DATA8
        Send : D0 03 43 00 F9 D4  <- OTP_ECC_DATAIN1
        Send : D0 03 44 00 FB E4  <- OTP_ECC_DATAIN2
        Send : D0 03 45 00 FA 74  <- OTP_ECC_DATAIN3
        Send : D0 03 46 00 FA 84  <- OTP_ECC_DATAIN4
        Send : D0 03 47 00 FB 14  <- OTP_ECC_DATAIN5
        Send : D0 03 48 00 FE E4  <- OTP_ECC_DATAIN6
        Send : D0 03 49 00 FF 74  <- OTP_ECC_DATAIN7
        Send : D0 03 4A 00 FF 84  <- OTP_ECC_DATAIN8

     b.CONTROL1[ADDR_WR] = 1.
        Send : D0 03 09 01 0F 74

     c.DIR0_ADDR = 0x00.
        Send : D0 03 06 00 CB 44

     d.COMM_CTRL[STACK_DEV] = 1, COMM_CTRL[TOP_STACK] = 0.(Set with broadcast write)
        Send : D0 03 08 02 4E E5

     e.COMM_CTRL[STACK_DEV] = 0, COMM_CTRL[TOP_STACK] = 1.(Set with single device write)
        Send : 90 00 03 08 01 D2 1D

     f.Dummy Read from ECC_DATA1 to ECC_DATA8.
        Send : C0 03 43 00 FD 14    <- OTP_ECC_DATAIN1
        Recv : 00 00 03 43 00 E5 30 -> Dummy Data
        Send : C0 03 44 00 FF 24    <- OTP_ECC_DATAIN2
        Recv : 00 00 03 44 00 E7 00 -> Dummy Data
        Send : C0 03 45 00 FE B4    <- OTP_ECC_DATAIN3
        Recv : 00 00 03 45 00 E6 90 -> Dummy Data
        Send : C0 03 46 00 FE 44    <- OTP_ECC_DATAIN4
        Recv : 00 00 03 46 00 E6 60 -> Dummy Data
        Send : C0 03 47 00 FF D4    <- OTP_ECC_DATAIN5
        Recv : 00 00 03 47 00 E7 F0 -> Dummy Data
        Send : C0 03 48 00 FA 24    <- OTP_ECC_DATAIN6
        Recv : 00 00 03 48 00 E2 00 -> Dummy Data
        Send : C0 03 49 00 FB B4    <- OTP_ECC_DATAIN7
        Recv : 00 00 03 49 00 E3 90 -> Dummy Data
        Send : C0 03 4A 00 FB 44    <- OTP_ECC_DATAIN8
        Recv : 00 00 03 4A 00 E3 60 -> Dummy Data

3.Do Fault Reset.
        Send : 91 00 03 31 FF 7F 4D 01  <- FAULT_RST1/FAULT_RST2

4.Read OTP Page Status.
        Send : 80 00 05 1A 00 3E BF  <- OTP_CUST1_STAT
        Recv : 00 00 05 1A 0F 7F 65  <- [PROGOK],[UVOK],[OVOK] and [TRY] = 1
        Send : 80 00 05 1B 00 3F 2F  <- OTP_CUST2_STAT
        Recv : 00 00 05 1B 8F 7F 55  <- [LOADED],[PROGOK],[UVOK],[OVOK] and [TRY] = 1

5.Read Shadow Registers.
        Send : 80 00 00 00 37 64 08
        Recv : 37 00 00 00 01 01 54 06 00 00 00 00 00 27 20 F2 <- DIR0_ADDR_OTP to CUST_CRC_LO
               00 00 09 09 09 09 00 00 00 00 00 00 10 00 00 00
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
               00 00 00 00 00 00 00 00 00 00 C3 AA

6.Read CUST_CRC_RSLT_HI and CUST_CRC_RSLT_LO
        Send : 80 00 05 0C 01 F1 1F
        Recv : 01 00 05 0C C3 AA 11 8A <- No difference from CUST_CRC_HI/LO


    Best Regards.

  • 0 in reply to Yoshihiro Kato
    TI__Expert 7060 points

    Yoshihiro,

    It seems like you need to send a WAKE ping instead of the soft reset after programming page two. I do not know why. I can converse with the designers and see if they have any further insight, but this seems like a workable solution, especially because you will very rarely have to program page two.

    Regards,

    Ben