• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 63 subscribers
  • Views 1409 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.

BQ51221 returns different values when reading RXID Readback via I2C (Except locations 0x01 and 0x02)

Majid Safari
Prodigy 145 points
Other Parts Discussed in Thread: BQ51221, DRV2605L, BQ51021, BQ51025, BQ27546-G1

Dear Sir/Madam

I used BQ51221 in my custom design to charge two 3.7V Li-Ion batteries.

I implemented the wireless charger in Back Cover solution and also connected the BQ51221's I2C pins to my microcontroller to be able to communicate with it.

There is also a DRV2605L device on the same I2C line which works with no problem. (I also checked the SCL and SDA signals by CRO and the waveforms are beautiful) (I am also sure that I am NOT communicating with BQ51221 and DRV2605L at the same time)

My question is if I read BQ51221's 'Wireless Power Supply Current Register 1' (location 0x01) and 'Wireless Power Supply Current Register 2' (location 0x02) with any speed via I2C I can read (write) the correct values all the time but if for example I read the 'RXID Readback' locations 0xF5 to 0xFA the returned values are different each time, whilst the RXID should be a 6 bytes constant value. Here it is some of my readings:

00 10 1D 54 DD DD

10 10 00 54 DD 00

10 10 00 54 54 DD

00 00 00 1D 54 00

00 10 1D 1D 54 DD

Why this is happening? This is also true for all other registers except locations 0x01 and 0x02.

My wireless charger is working, it means when the battery is almost charged the Vout is 5.02V constantly, the Vrect is 6.89V to 7.23V (when the primary/secondary coils are aligned). I also checked the Vrect using a CRO so the Vrect is not dropping (even not momentarily) under the Vuvlo.

I just have no clue why this is happening.

I look forward to hearing from you.

Kind Regards,

Majid

  • 0
    TI__Genius 14890 points

    Majid,

    Thank you for the detailed investigation.

    We have done extensive testing and have not seen this before.  Have you tried multiple bq51221 units?

    What transmitter are you using during the read?  (WPC, PMA and model number if possible.) 

    It is interesting that each byte you show has only 2 values.  This indicates it is not a corrupted read or corrupted register location.  Can you detail how your I2C bus is configured (pull-up voltage, pull-up resistors).

    Regards,

    Dick

  • 0 in reply to Dick Stacey
    Prodigy 145 points
    Dear Dick

    Thanks for your answer.

    1. Q: '... Have you tried multiple bq51221 units?'
    A: Yes, I did. I have 6 units and all of them have this issue.

    2. Q: 'What transmitter are you using during the read?'
    A: My power transmitter is a NOKIA Wireless Charger Plate model DT-903 (Output 5W, Input 5.2V 2.5A) and it is a Qi device (WPC).

    3. Your Comment: 'It is interesting that each byte you show has only 2 values. This indicates it is not a corrupted read or corrupted register location'
    My Comment: Indeed. The speed that I use to communicate via I2C is about 92KHz (which is below the bq51221's maximum speed 100kHz) and I tried the lower speeds with same issues. The interesting thing is the read/write process for locations 0x01 and 0x02 is ALWAYS correct with any speed. What ever I write into these two locations, I can read the same values all the time.

    4. Your Comment: 'It is interesting that each byte you show has only 2 values.'
    My Comment: Oh, it is interesting. Do I need to assert a delay between reads? I tried to different ways of reading the RXID; locations 0xF5 ~ 0xFA:
    a. Reading each location one by one by providing the location address and read 1 byte.
    b. Reading all six location by providing the first address (location 0xF5) and read for 6 bytes.
    In both ways, the issue exist. My conclusion is that there is nothing wrong with neither I2C lines nor with the way I read I2C (I mean code) devices.
    I wonder if the type or nature of memory for locations 0x01 and 0x02 are differ from the rest of the locations? (You may know this better than me)

    5. Q: 'Can you detail how your I2C bus is configured (pull-up voltage, pull-up resistors).'
    A: I have two pull up resistors close to the microcontroller (which is EZR32WG330F256R68G) on SCL and SDA lines with value of 4.7K
    The SCL and SDA lines of both BQ51221 and DRV2605L are connected to the microcontroller through four separate 200R resistors. As I mentioned in my last post the haptic device is working with no issue at all and the waveforms on SCL and SDA are clean.

    I look forward to hear from you.

    Kind Regards,
    Majid
  • 0 in reply to Majid Safari
    Prodigy 145 points

    Dear Dick

    I've found the problem. It is about timing requirement by I2C line on BQ51221.

    I tried two more different power transmitters as well as different power sources with different output current, the issue still was there. Then I monitored the I2C SDA line on Scope and matched it with what I was reading by my code. Everything matched up. After that, my attention has been directed to the line (I2C) timing and I changed it, BINGO, all readings and writings to/from BQ51221 device are correct.

    I noticed that there is no 'Timing Requirement Table' for I2C available in BQ51221 datasheet, this part of specification is also absent in BQ51021 and BQ51025 device's datasheets (these two devices support I2C communication as well).

    Good news was, my other device; DRV2605L; on this line (I2C), has this information present in its datasheet which helped me to fix the timing problem. It might be useful for somebody if I mention that the problem was about tw(H) 'pulse duration, SCL high' and tw(L) 'pulse duration, SCL low' requirement. The ratio was 4:4 which I changed it to 6:3 (the ratio between low period and high period counters on my microcontroller in master mode).
     
    My initial thought was that the timing specification on I2C, for both BQ51221 and DRV2605L devices are the same (because that part was absent from datasheet, so I assumed that I can follow the TI's I2C general timing rule), which is obviously not.

    It would be very useful if this timing table could be added into the wireless receiver device's datasheets which support I2C such as BQ51221, BQ51021 and BQ51025.

    Cheers,
    Majid

  • 0 in reply to Majid Safari
    TI__Genius 14890 points

    Majid,

    Great work!  Glad you resolved the issue.  I had evaluated the bq51221 with our standard interface (no characterization) and had no issues.  I will evaluate the I2C timing, with emphasis on the issue you've seen.

    Thank you for the input on the datasheet.  Based on the results from the characterization, we'll update the datasheets accordingly.

    Regards,

    Dick

  • 0 in reply to Dick Stacey
    Prodigy 145 points
    Dear Dick

    Thank you.

    Cheers,
    Majid
  • 0 in reply to Majid Safari
    Prodigy 130 points

    Dear Majid and Dick,

    I follow this topic and saw you now can communicate I2C interface between MCU and BQ51221 (Receiver IC). 

    I would like to ask one question about: Could I get information ""Charger status" that conveys the level of battery charger - It is that how many percentage of battery charger is remaining when I  communicate I2C interface between MCU and BQ51221 (Receiver IC). If possible tell me how to get this information or how to calculate this information?

    Thank you for your helps!

    Rregards!

    Son

  • 0 in reply to Son Nguyen Duc
    TI__Genius 14890 points

    Son,

    The bq51221 does not have that information.  It must be sent to it via I2C.  A gas gauge, such as the bq27546-G1 has this information.  The host can talk to both through I2C to transfer the information.

    Regards,

    Dick