• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 289 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.

BQ76952: OTP Fail (BatteryStatus() bit[ss] is set, but no safety faults are found)

Kyungjae Lee
Intellectual 660 points
Part Number: BQ76952
Other Parts Discussed in Thread: BQSTUDIO,

Tool/software:

Hi,

I have been following the guide "BQ769x2 Calibration and OTP Programming Guide" to perform OTP without using the bqStudio, and I'm failing at the step "Read OTP_WR_CHECK() (Subcommand 0x00A0)" where I'm getting 0xFF instead of 0x80.

Precondition:

- 10-12V applied to the BAT pin

- No safety faults (See the evidence below)

- BQ76952 not custom configured yet and is still in its default configuration

Analysis:

My only suspicion is that the Battery Status() showing that I have at least one enabled safety fault triggered.

However, I didn't have any faults triggered according to the SafetyStatusA/B/C as shown below:

Any advice to further investigate this issue?

Thank you,

Kyungjae Lee

  • 0
    TI__Genius 17945 points

    Hello Kyungjae,

    Usually if the value returned is 0xFF, it indicates the subcommand has not completed operation yet, or that you’re reading to quickly after writing. I recommend using a 2ms wait time in between to see if that helps. It is unusual that the Battery Status is indicating a Safety Fault is triggered though. Can you check the Safety Alerts as well to see if anything triggered there?

    I would also make sure the 10-12V is also applied to the highest pin (VC16 for BQ76952) when programming OTP or else the device will not allow OTP programming (BQ76952 OTP Programming FAQ).

    Best Regards,
    Alexis

  • 0 in reply to Alexis_H
    Intellectual 660 points

    Hi Alexis,

    Thank you for the clarification. Following your recommendation, I've increased the time between write_reg() and read_reg() in 2ms increments to give the AFE enough time to process the command and update its register with the correct values. When the delay reached 10ms, I began receiving the correct response (0x80 instead of 0xFF).

    Is this the right way to find the sweet spot for my environment, or is there a potential issue since 10ms is five times longer than what you suggested?

    Thank you,

    Kyungjae Lee

  • 0 in reply to Kyungjae Lee
    TI__Genius 17945 points

    Hello Kyungjae,

    Glad that you were able to find the amount of time needed to help with processing the command! This method is fine to find the right amount of time needed. It is not an issue that 10ms is 5x longer than what I suggested. For some users, they have waited 100ms to be safe. An extra note, I will be Out of Office until next Tuesday, so I won’t be available to reply until then.

    Best Regards,
    Alexis