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.

BQ4050: SMBus communication

Part Number: BQ4050
Other Parts Discussed in Thread: EV2400

Tool/software:

Hello experts,

Currently my customer is using our EVM to test BQ4050 for their robot vacuum pjt.

Below is a waveform of SMBus communication (CH1 : CLK, CH2 : DATA) and they have connected the BQ4050EVM directly to their vacuum robot set, to do communication with their main board MCU, instead of their PC using EV2400.

With the CLK waveform, the HIGH voltage level is around 1.3V, with duration of around 5.33us. LOW is around 0.18V.

  1. Could you please check if the SMBus waveform is ok, in terms of Data & Clock lines' HIGH & LOW voltage level, duration, etc., and share your feedback with me?
  2. They found spike-like waveforms, as marked in blue below, repeatedly. Would this be the Data line failing to go HIGH? Is this something that may happen frequently?
  3. For the spike-like waveforms, may I ask what could be the potential cause of this?

Thank you in advance for your help and support.

Best regards,
Jade

  • Hi Jade,

    We would need to know the exact timing of each part of the transaction to confirm the waveform, however the communication waveform must fit the specifications below:

    Regarding the 1.3 pull up voltage, please be careful since this is the minimum input high voltage for these pins:

    Regards,

    Anthony

  • Hi Anthony,

    Thank you for your feedback.

     Could you please share your feedback on these questions as well?

    • They found spike-like waveforms, as marked in blue below, repeatedly. Would this be the Data line failing to go HIGH? Is this something that may happen frequently?
    • For the spike-like waveforms, may I ask what could be the potential cause of this?

    Thank you for your support.

  • Hi Jade,

    It is difficult to know what these spikes are without seeing the entire structure of the byte being processed. This could potentially be an ACK from the device.

    Regards,

    Anthony