Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 65 subscribers
  • Views 189 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BQ76930: some doubts of RSVD bit of SysCtl1

David Rich
Prodigy 155 points
Part Number: BQ76930

Tool/software:

Hi team,

Recently our customer feeded back there were some batteries stop charging / discharging because the malfunction of smapling cell voltages.

Our BMS use two bq76930 in serial to support 20S LFP cells management. The 2nd bq76930 stopped updating the cell voltages.

By monitoring the I2C communication, we found that the SysCtl1 value was 0x64.

According to the definition of SysCtl1, the RSVD bits of bit2, bit5, bit6 were set to 1, the bit4(ADC_EN) was cleared to 0.

We have rectified this error by change the opreation method of SysCtl1.

But we still want to know the following questions:

1) The meaning of those bits of SysCtl1?

2) In which conditions it will be set to 1?

3) why this error only happens to the 2nd bq76930?

Thanks!

  • 0
    TI__Mastermind 36330 points

    Hello David,

    These bits are private bits, so we cannot share what are their meanings

    Has the top IC by any chance POR'd? I wonder if it reset and that caused the ADC to become disabled. In what conditions do you find this happening?

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Prodigy 155 points

    Hi Luis,

    Until now we just found the top BQ76930 had this kind of issue. Those two chips use the same driver program and same configuration. It happend randomly, such as discharging or charging.

    As you pointed out the POR, we can't sure there were any change to it because the records didn't show any clue. Could you please help to identify in which condition bit2 of SysCtl1 will bet set as 1? That may give us some clue.

    Best Regards

    Thanks!

  • 0 in reply to David Rich
    TI__Mastermind 36330 points

    Hello David,

    I can look into it. But I would see if it is possible to catch when this happens, and possibly if there are any disturbances while charging/discharging, of the supply lines.

    Section 8.4.2 SHIP Mode of the datasheet talks about the risks here if the part were to POR. 

    Meanwhile, I will see if I can find if there are any specific causes for SYS_CTRL1 setting bit 2.

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Prodigy 155 points

    Hi Luis,

    Thanks for your reply.Is there any information?

  • 0 in reply to David Rich
    TI__Mastermind 36330 points

    Hello David,

    Yes! I did find that if the RSVD is set to 1, it will disable the voltage/current ADC and OCD/SCD protections.

    This bit would only change if it is being written to, I am not sure if some communication error caused it to change to one, but should not be able to change on its own. Setting this bit back to 0 should be able to re-enable the ADC/OCD/SCD.

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Prodigy 155 points

    Hi Luis,

    There is CRC validating for this part. I'm pretty sure that won't cause SysCtl1 bit2 change to 1 and won't trigger the CRC error.

    We had went through the BMS codes. It only write SysCtl1 when initiating or SysCtl1 ADC_EN equals to 0. Then the wiered thing happend: why/when ADC_EN bit was set to 0 and RSVD bit2 set to 1? 

    Thanks for you help!

    BR

    David

  • 0 in reply to David Rich
    TI__Expert 6600 points

    Hello David,

    Thank you for your patience. This engineer will be back tomorrow to answer your question.

    Best Regards,
    Alexis

  • 0 in reply to David Rich
    TI__Mastermind 36330 points

    Hello David,

    As I mentioned, ADC_EN is set to 0 when bit 2 is set to 1. 

    Bit 2 would not change unless being written to, I am not sure why in your case this happened, but it should not change on its own.

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Prodigy 155 points

    Hi Luis,

    We have tested writing bit2 of SysCtl1 to 1 and reading back. Yes, it is 1.

    But we went through our codes, it's barely not possible to write 1 by MCU.

    Is there any possibility that it was changed by AFE under some cases? Please help to confirm with R&D team.

    Best Regards,

    David

  • 0 in reply to David Rich
    TI__Mastermind 36330 points

    Hello David,

    I did look into our internal documentation, and this bit is described to not be changed unless written to. So as far as normal operation goes, this bit should never change based on what is going on with the device.

    Apologies about the non-satisfactory answer. 

    I am aware you have CRC-enabled communications, so not entirely sure how this change could be happening here.

    How often does this type of error happen? Has it happened to multiple packs?

    Best Regards,

    Luis Hernandez Salomon

  • 0 in reply to Luis H. S.
    Prodigy 155 points

    Hi Luis,

    Recently, we had received about 20 cases with the same error which we are discussing, the 2nd Bq76930 stopped to update cell voltages. It happended randomly, such as during discharging/Charging/Relaxing.

    BR,

    David

  • 0 in reply to David Rich
    TI__Mastermind 36330 points

    Hello David,

    That is interesting. Has this also been able to occur in a lab environment? I am trying to understand if there's any conditions that could lead this to happen.

    Or maybe a MCU hiccup that sent the wrong command sequence. 

    Best Regards,

    Luis Hernandez Salomon