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

BQ Studio Programming File and Data Flash Comparison

Brett Henne
Prodigy 100 points

Other Parts Discussed in Thread: BQ27742-G1

I'm using a BQ27742-G1.  We are trying to figure out the programming script protocol using the golden image DFFS that we generated in BQ Studio.  The safety subclass on our device was setup to have the following data starting at offset 0:

(10 8B 01 10 4F 09 C4 01 0A 8C 00 3C 02 26 00 01 F4 02 8A 01 02 58)

The DFFS golden file was generated and I was able to find the section for programming the safety subclass ID, however it contained more bytes.  Here is a partial portion of the DFFS file:

W: 16 00 0A 12 00 00 00 00 00 00
W: 16 08 10 8B 01 10 4F 09 C4 01
W: 16 10 0A 8C 00 3C 02 26 00 01
W: 16 18 F4 02 8A 01 02 58 10 B3
W: 16 20 10 CC 10 E5
W: 16 64 4F 07
X: 2
C: 16 66 00

Why is the first byte in each row 0x16?  The internal address of the device is 0xAA/0xAB for write/read.  I couldn't find any reference to this in the datasheet.  I assume it is the internal address of the data flash?  Not really sure, but I would like to understand.

The second byte in each row appears to be an offset.

The next set of bytes are (0A 12 00 00 00 00 00 00), where did these come from?  In the script every section increments the second byte by on (0A 13, 0A 14, etc).  Again, what are these bytes? 

The next set of bytes are the safety subclass ID bytes (10 8B 01 10 4F 09 C4 01 0A 8C 00 3C 02 26 00 01 F4 02 8A 01 02 58).  We know these bytes.

The second to last set of bytes is also unknown.  (10 B3 10 CC 10 E5)

And lastly these are also unknown.

W: 16 64 4F 07
X: 2
C: 16 66 00

We use a lot of these devices on our products but no one really knows what is going on in the programming file.  Any assistance would be appreciated.

- Brett

  • 0
    TI__Guru* 76230 points

    hi Brett,

    Programming of the gauge is done in ROM mode. The address of the gauge in ROM mode is 0x16, hence the reason you see each line starting with 16. In firmware mode, the address is 0xAA. 

    pls review the attached  app note. It describes the commands in detail and should address most if not all your questions. Let me know if you have further questions.

    One more thing that app note doesn't cover is the C:16 66 00. 

    C is read and compare  command to verify the integrity of what was written to the gauge. Address 66  is the status byte and the 00 means operation was successful. That line being repeated through out the flash stream file ensures that what you are writing to the gauge is actually being written,

    2553.slua541.pdf

    thanks

    Onyx

  • 0 in reply to Onyx Ahiakwo
    Prodigy 100 points

    Onyx,

    Thanks for your response, the application note really helped.  Is there any way you can shed some light on the bytes before and after the subclass ID bytes?

    This set:

    W: 16 00 0A 12 00 00 00 00 00 00

    And this set:

    W: 16 18 F4 02 8A 01 02 58 10 B3

    W: 16 20 10 CC 10 E5

    W: 16 64 4F 07

    - Brett

  • 0 in reply to Brett Henne
    TI__Guru* 76230 points

    Hi Brett,

    Unfortunately, i do not have access to know what each byte represent.

    thanks

    Onyx