• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 6 answers
  • Subscribers 63 subscribers
  • Views 343 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.

BQ40Z50-R2: BQ40Z50-R2 Data Hold Time

Zhihan Zhang
Expert 1100 points
Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQ20Z80, BQ40Z50, BQ20Z45

Hi TI Team,

I'm currently working on BQ40Z50-R2 to replace BQ20Z80 chip. For the datasheet, SMBus part, for Data Hold Time, I found some difference. For older BQ20Z80, data hold time has 2 mode: receive mode (0ns min) and transit mode (300ns min). However, for BQ40Z50-R2, there is no receive or transit mode, only 300ns min. So my questions are:

1. Is there any particular reason that you make such adjustment?

2. Is receive or transit mode still available in BQ40Z50-R2 but just hidden?

3. If 0ns min receive mode is not available in BQ40Z50-R2, does that mean that host device always needs to make sure the data hold time to be > 300ns?

4. What's the effect to the fuel gauge IC itself when there's no receive mode?

Thanks,

Zhihan

  • 0
    TI__Guru** 105590 points

    Hello Zhihan,

    The definition for SMBus data hold time is 300ns, it may have been included in the older chips datasheet for more clarity if needed.

    If your host is operating with the SMBus standard it will not need to be changed.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1100 points

    Hi Wyatt Keller,

    Thanks for the reply!

    Since the data hold time has been changed in the new IC. Does that mean that there is no receive or transit mode difference for BQ40Z50-R2 regarding the data hold time? Or for BQ40Z50-R2, when receiving data, the data hold time must be > 300ns, the same as transit mode?

    Additionally, our host seems to be designed referencing BQ20Z80 datasheet, there is receive and transit mode difference for data hold time. So in order to communicate with BQ40Z50-R2 device, data hold time will need to be adjusted accordingly right? To be adjusted to comply SMBus standard or BQ40Z50-R2's spec since the data hold time part is the same.

    Thanks,

    Zhihan

  • 0 in reply to Zhihan Zhang
    TI__Guru** 105590 points

    Hello Zhihan,

    There would be no difference in the delay time between transmit or receive, they're both 300ns.

    Yes I would add the delay since it is the protocol for SMBus, it was probably corrected in the bq40z50 to match the standard more consistently.

    Sincerely,

    Wyatt Keller 

  • 0 in reply to Wyatt Keller
    Expert 1100 points

    Hi Wyatt Keller,

    Thank you for your reply!

    Is it possible that you can confirm the "data hold time" part is corrected in BQ40Z50-R2? Because not only BQ20Z80, but also other older ICs such as BQ20Z45, BQ20Z60, etc has same data hold time description. They all have different timing requirement for receive and transmit.

    Additionally, the host device was designed referencing older IC (e.g. BQ20Z80) spec, it may be difficult to adjust on the host side. So is there anything we can do on the BQ40Z50 device side? And is there any possibility to add the old feature (e.g. 0ns for receive mode of data hold time) back to BQ40Z50 in the future maybe firmware update?

    Thanks again for your help!

    Regards,

    Zhihan

  • 0 in reply to Zhihan Zhang
    TI__Guru** 105590 points

    Hello Zhihan,

    The gauges have updated parameter to match the standard for SMBus, I would follow what the TRM recommends using the delay for both transmit and receive.

    I don't believe the firmware will be updated to match with the older gauges, a similar engine may be used for the SMBus in the bq40z50 as the older gauges. You can try to test to see if the hold time is needed but we always recommend to follow the TRM.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1100 points

    Hi Wyatt Keller,

    Thank you for your reply! We will just follow SMBus standard and BQ40Z50 datasheet. And will try on the data hold time.

    Just curious, is there any particular reason for the older ICs not entirely following SMBs 1.1 regarding data hold time?

    Thanks agian,

    Zhihan

  • 0 in reply to Zhihan Zhang
    TI__Guru** 105590 points

    Hello Zhihan,

    I'm not entirely sure why more parameters were given than necessary for the standard.

    Section D.3.3 in this article might be helpful: smbus.org/.../SMBus_3_1_20180319.pdf

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1100 points

    Hi Wyatt Keller,

    Thank you for your answer and article. They are very helpful!

    We have tried on the host with bq40z50 device. We met some issue. Based on the measurement, 2 parameters seems not meet SMBus standard & bq40z50. They are data hold time (SMBus) and output low voltage (bq40z50). I'm wondering do you have any suggestion to improve those 2 parameters?

    Additionally, you mentioned similar engine is used for bq40z50. So just curious, if data hold time is wanted to match the old IC, like add receive mode with minimum 0ns. Will that require a change in silicon or just firmware update?

    Thanks,

    Zhihan

  • 0 in reply to Zhihan Zhang
    TI__Guru** 105590 points

    Hello Zhihan,

    What was the issue you ran into with the host? Was it miss some packets and NACKing?

    If the engine was changed to match the standard it may not be possible to update them to previous specs with firmware.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1100 points

    Hi Wyatt Keller,

    Thank you for reply!

    So for the communication error, please see below example:

    When the host tries to access temperature, the packet will look like below:

    1. 0x16

    2. ACK bit, except logic low voltage is > 0.4V, it's around ~0.5V.

    3. 0x08

    4. NACK bit

    5. Repeat steps 1 ~ 4 again.

    The above phenomenon can appear on any command like current, voltage or etc. Once the phenomenon appears, the packet will not be intact and the host will keep repeating steps 1 ~ 4 for couple times then eventually send out an error message. From the measurement on the waveform, log low voltage exceeds 0.4V and data hold time is < 300ns.

    So is there any improvement can be done on the device side if the host can't be modified?

    Thanks,

    Zhihan

  • 0 in reply to Zhihan Zhang
    TI__Guru** 105590 points

    Hello Zhihan,

    Sometimes when the line low is too high the pull-up resistor is too low of a value, I would check to make sure you have the correct size resistors for your communication bus.

    The gauge could be nacking if the voltage is getting too close to the threshold.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Zhihan Zhang
    Expert 1100 points

    Hi Wyatt Keller,

    Any comments or suggestions regarding above issue?

    Additionally, can you please clarify the following question from our host side engineer?

    If similar engine as older gauges for SMBus can be used by changing firmware, or if it requires silicon change? If engine can be changed to match the older gauges with firmware change, please advise how quickly we could get samples?

    Thanks and regards,

    Zhihan

  • 0 in reply to Zhihan Zhang
    TI__Guru** 105590 points

    Hello Zhihan,

    I would reference this guide for selecting the I2C pull-up resistors: www.ti.com/.../slva689.pdf

    I would need to check with our designers if the silicon has been changed between the gauges, but either way it would not be possible to edit the firmware to accommodate for the change as it is very complex and would require a custom firmware release which is rare.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1100 points

    Hi Wyatt Keller,

    Any updates on whether the silicon has been changes?

    Thanks,

    Zhihan