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

BQ34Z100-G1: Parsing and using the DF FS file to update parameters

Neil Jacobson
Prodigy 240 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQSTUDIO, BQ34Z100

I have a df.fs file generated from bqStudio. I found a parser and explanation of the contents. What I have not found is a way to validate that what I am doing is actually working and if it is not what is wrong.  I get that once you go into ROM mode the I2C address changes from AA to 16 so the enter and exit operations are easy to validate. The in-between stuff is not quite so easy. What I am doing with a line like

W: 16 00 03 00 00

is breaking it into individual I2C byte writes at incremented addresses as follows

at slave address 16

write address 00 with data 03

write address 01 with data 00

write address 02 with data 00

I do that with every W line. The device responds with an ACK as expected

Then when I get a C I do something similar

C: 16 66 00

turns into

at slave address 16

read address 66

compare byte returned with 00

Everything seems great until I get the line that looks like this:

C: 16 04 B5 44 6A D4

In that case

at slave address 16

I read a byte from 04, 05, 06, 07 in succession

I always seem to get all 00 from each byte

Can you explain the error of my ways?

Thanks

 

  • 0
    TI__Mastermind 25955 points
    Hi Neil,

    The C command stands for read and compare one or more bytes of data.

    For C: 16 04 B5 44 6A D4

    The 4 bytes B5, 44, 6A and D4 are expected to be read back from the register address 0x04 of the device addressed at 0x16. An error should be thrown if the the contents read back from register 0x04 do not match.

    For more information on the DFFS format, please refer to: www.ti.com/.../slua541a.pdf

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 240 points

    OK. I get that it's an error but what would be the root cause of the error? What could I have done wrong in the steps I described that causes the error? I see all zeros returned from 0x04. 

  • 0 in reply to Neil Jacobson
    TI__Mastermind 25955 points
    Hi Neil,

    For I2C:

    The read and compare command is formatted identically to the write command. The data presented with
    this command matches the data read exactly, or the operation ceases with an error indication to the user.
    The format of this sequence is:
    "C: i2cAddr RegAddr Byte0 Byte1 Byte2".

    An example of this command is as follows:
    C: AA 55 AB CD EF 00

    This example expects the master to read back 4 bytes from the register address 0x55 of the device
    addressed at 0xAA and then compare the data to the values given on the line command in this same
    order as 0xAB, 0xCD, 0xEF, and 0x00.

    Another good resource for creating a DFFS parser is this document: www.ti.com/.../slua801.pdf

    Assuming the code and communication between the device is good, please send me your SREC and DFFS so I may test internally.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 240 points

    I have a df parser and I believe it is performing correctly. I am only loading the dffs and not the srec because I found multiple sources on this board that suggested that loading the srec is unnecessary in a normal device. I was wondering why the status from the 66 register is always good but the 04 is always bad. That has to be a hint of something

    How do I send you my DFFS file

  • 0 in reply to Neil Jacobson
    TI__Mastermind 25955 points
    Hi Neil,

    Please zip your srec and dffs file and attach it to this thread.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 240 points

    I think I found the root cause(s) of my issues

    (1) The df parser code that I grabbed from the example has a df line length statically defined to be 64 bytes. While that may have been sufficient for whatever device it was originally written for, the BQ34Z100 has lines that are easily twice that long. The code as written simply ignored the extra data. This resulted in the device being only partially programmed which was causing the device to be bricked.

    (2) The delay times specified in the X records were insufficiently long to complete the operations that preceded them. This was causing the status checks and compares to fail. I found that there were a number of delays specified as 2 (msec) and I had to increase them to 200 or more to pass. Perhaps the intent is to poll every 2 msec? But then, it seems some maximum ought to be specified

    I have attached my df.fs filedf.zip