• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1146 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.

BUG in bq78350 firmware?? ManufacturerAccess() 0x0059 AFEVConfig

Michal Radziwon0
Prodigy 145 points
Other Parts Discussed in Thread: BQ76930, BQSTUDIO

Dear fellows,

I have recently encountered a weird behavior of ManufacturerAccess() 0x0059 AFEVConfig command for bq78530 (firmware 0x006 29 Sep 2014 ).

According to description it should return configuration data of companion AFE (address 0x01 to 0x0B) in string format (11+1 bytes) with no unit assigned (some other data in string format is explicitly said to be of ASCI "units").  However, execution of such command results in:
0x[ 0E 74 00 64 1F 40 00 00 3C 0A 02], which hardly can be true, as when reading data directly from AFE by I2C results in 0x[80 00 00 00 10 43 00 00 50 C5 18 19]. The mismatch is especially striking because of two facts - 0x0B byte shall be 0x19 according to AFE datasheet (bq76930) and it is so when reading directly from AFE. The second issue is the fact that execution of subsequent SMB commands 0x005A, 0x005B should result in reading of subsequent memory blocks - while the result seems to be different lengths of read command from the same data address.

  • 0
    Intellectual 795 points

    Michael I'm going through the same thing right now with the same chip when reading ManufacturerAccess()  Block Read address 44. 

    I can tell you that the ManufacturerAccess() 0x0060 command written and read from address 44 will return different data like you are seeing depending on if you have the chip in Sealed or Unsealed mode. 

    So if you have your chip in Unsealed Mode you will probably get the wrong data your seeing. Try putting the gauge in Sealed mode and then read from that address and see if the data is correct. That's the way its working for me on the 0x0060 address. 

    Hope that makes sense. 

  • 0 in reply to Ryan Brown2
    Prodigy 145 points
    To be honest - it does not make any sense to me.
    Especially - that there is no mention of such behavior in datasheet.
    But thanks for tip! I will test is tomorrow and let you know here if my results will render the same.
  • 0 in reply to Michal Radziwon0
    Intellectual 795 points

    Yea there is lots of missing and incorrect data in the manuals. Very frustrating.

    I can assure you that you will see different returned data depending of the Fuel Gauge is Sealed or Unsealed. 

  • 0 in reply to Ryan Brown2
    TI__Guru 54715 points

    AFEVConfig is a MAC command, so send as a word to command 00 then read back as a block.  Be sure there is no communication between your command and your block read.  If using bqStudio be sure to turn off register scan, also you may want to stop the dashboard timer update.  Command & response should look something like this:

    Address , Operation , Command , Length , Data , Status ,
    17 , Wr Word , 00 ,   2 , 0059 , Success
    17 , Rd Block , 44 , 13 , 59 00 00 00 00 18 40 00 00 50 C7 19 19  , Success

    If you read from command 23 instead, you don't get the command repeated in the data ( 2 bytes shorter):

    17 , Rd Block , 23 , 11 , 00 00 00 18 40 00 00 50 C7 19 19  , Success

    MAC commands 005A and 005B read data which is in a structure using a command protocol, not necessarily in an address.  The i2C address in the AFE is described so you can see the format of the data and where it came from.  If you read from the AFE on I2C to compare, be sure to disconnect the gauge since there is no arbitration for the bus.  Without disconnection of the gauge from the bus you may read bus collisions and cause the gauge to initiate a register update which may cause more collisions.  Also note that the AFE value registers will be updating and exact data comparisons may be difficult.

  • 0 in reply to WM5295
    Prodigy 145 points
    Thanks -great advice!

    That makes it clear now, why I was getting weird values.