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

BQ78350: Communication problems using I2C instead of SMBUS

Jarni V
Prodigy 20 points
Part Number: BQ78350
Other Parts Discussed in Thread: BQ76940, , , EV2400, BQSTUDIO


For a project we are using BQ78350 in combination with a BQ76940.

Our firmware drivers do not support smbus but we created our own implementation for the communication using the nrf_twim drivers.

  1.  We are following the Technical Reference Manual for BQ78350-R1A,
    if we follow the ManufacturerAccess() information we see that we should be reading 2 bytes for the size of the data. But when we are doing the same we only receive 1 byte for the size.
    For ManufacturerBlockAccess(), we receive 1 byte indicating the size (with the 2 bytes of the command included), the 2 bytes for the command and following the data bytes, this also does not match our reference manual. This is a capture from a logic analyzer.



  2. We are also having acknowledgement errors when sending / receiving, both on the address and the data.
    This does not always happen but we don't find the cause of the problem but this is causing problems in our current project.
    We are using I2C at 100kbs / there are no other devices on the same lines / we have pullups to 2.5v (We tried using 3.3V) / The communication by EV2400 seems to work fine.

  • 0
    TI__Guru 57697 points

    Hello Jarni,

    1. Size is only 1 byte and not 2 bytes

    2. During normal operation some no acknowledges are expected. The host must retry after a few milliseconds in such cases

  • 0 in reply to Shirish
    Prodigy 20 points

    Thank you for your quick reply,
    How many milliseconds would you suggest to be between the retries?
    Do you know where I can find more information about the acknowledges?

    Also here is a screenshot of the technical reference manual, is this a mistake? Or am I looking at the wrong manual?

  • 0 in reply to Jarni V
    TI__Guru 57697 points

    Hello Jarni,

    We use a random delay of between 10ms and 250ms.

    The TRM section references command 0x23 whereas the capture is for command 0x44. Both have different behavior.

  • 0 in reply to Shirish
    Prodigy 20 points

    Sorry I should have provided more information,

    When we use the ManufacturerAccess() we see that the byte order is the same as for ManufacturerBlockAccess() as for ManufacturerAccess() 
    And for size we only see 1 byte for ManufacturerAccess() just like ManufacturerBlockAccess()

    ManufacturerAccess() 

    ManufacturerBlockAccess()

  • 0 in reply to Jarni V
    TI__Guru 57697 points

    The 1 bye size is part of the SMBus standard. The 2 byte size in the TRM refers to the actual data that is received.

    Check using bqStudio Advanced comm if the block data read contains the 2 byte size when using command 0x23. Since there are 2 separate paragraphs with the same description, it is likely that there is a mistake in one of them in the TRM

  • 0 in reply to Shirish
    Prodigy 20 points

    I think BQStudio only uses ManufacturerBlockAccess() and not ManufacturerAccess(),
    When I follow the TRM but for ManufacturingStatus 0x0057 instead of LifetimeDataBlock1


    a. Send LifetimeDataBlock1() command through the ManufacturerAccess(): SMBus Write Word of 0x0060 to command 0x00.
    b. SMBus Read Block of command 0x23: The first two bytes of the return block will be the data length and the next bytes will be the data of the command.

    The 2 byte size is not being sent.
    Also the write word function in BQStudio Advanced Comm SMB sends 0x0057 as 0x5700, do we need to do the same writing a word? 
    When testing we see that both are working: 0x0057 and 0x5700

    0x0057


    0x5700


    This is a ManufacturerBlockRead() using BQStudio


  • 0 in reply to Jarni V
    TI__Guru 57697 points

    Hello Jarni,

    Word writes require LSB to be sent first. So send 0x57 0x00 to write 0x0057.

    MSB first will not work. It is probably an unused command and was ignored by the gauge leading to a correct response.

    I think that the 2 additional bytes are only sent when using AltManufacturerAcess()