FlashStream file commands undocumented

Hi Gerry,

Pls see the attachement. It contains explanations of the different commands and should clear any confusion. pls refer to flash stream file format pdf and slua541 pdf docs in the folder.

4718.2541.FlashStream028_bundle (2).zip

The information in 2541.FlashStream028_bundle (2).zip just goes over the same ground as other documents I have read. What I need is more detail about what is going on with the various ROM based commands. So in the sequence :

W: 16 00 03 00 00 

W: 16 64 03 00

X: 20

C: 16 66 00

W: 16 00 02 00 00 00 EA FF 33 24 FA 33 B8 FA 33 3D FE 33 45 FE 33 FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F 00 04 3F 58 CB 33 DB 00 08 00 00 00 00 00 00 FF AA 0E FB A7 0E FF A6 0E FF A1 0E FF A0 0E FE A3 0E 77 A2 0E D2 FF 3A FF A1 0E 66 A0 0E FF A3 0E

W: 16 64 1B 35

X: 2

C: 16 66 00

W: 16 00 02 01 00 00 64 A2 0E BD A5 0E 2F A4 0E CA FF 3A FE A1 0E 77 A0 0E FE A3 0E 77 A2 0E CA FF 3A C2 FF 3A D6 FF 33 FF AF 0E 01 4F 03 3F 11 0C CD FF 30 D4 FF 35 2F 10 0C D4 FF 35 FF FF 23 01 AF 14 01 4F 03 3F 11 0C C5 FF 30 CC FF 35 2F 10 0C CC FF 35 FF FF 23 FF DF 0B C4 FF 33 60 F6 39 FE AF 16 C1 AB 0E

W: 16 64 7A 2E

X: 2

C: 16 66 00

W: 16 00 05

W: 16 64 05 00

X: 170

C: 16 66 00

C: 16 04 93 2D 8D D3

W: 16 00 0C 00 00 00 83 DE

W: 16 64 6D 01

X: 200

C: 16 66 00

 

The only thing that is clear are the delay directives 'X: nnnn' , everything else is like reading a hex dump.

 

W: 16 00 ..........   what does this do?

W:16 64 ...      what does this do, it looks like it may be a two byte checksum, if so how is it calculated?

C:16 66 00                               what are we checking for here?

C: 16 04 93 2D 8D D3             what is this

W: 16 00 0C 00 00 00 83 DE

W: 16 64 6D 01   <-   ????

 

 

Hi Gerry,
The flashstream format document explains what each of the commands means. Pls review this document for a thorough understanding of what is going on.

When the gauge is in ROM mode, it's address is 16. When in firmware mode, the address is AA. When you review the flashstream file created by bqstudio (pls use bqstudio to create your flashstream files and not the flashstream tool contained in the folder i sent you) , you will see the sections that says verify firmware version. The example below is from our bq27742 device with version 1.03 firmware on it.

;Verify Existing Firmware Version
;--------------------------------------------------------
W: AA 00 01 00
C: AA 00 42 07
W: AA 00 02 00
C: AA 00 03 01

The W indicates you are writing to device address AA, register 00 data 01. (note that in order to read from the device you must first write to the specific register). Also, note that the subcommand in the technical reference manual for reading the device type is 0x0001. Since I2C on all our devices is little endian, hence the LSB is writen first before the MSB that is why you have 01 first then 00.

The next command C: AA 00 42 07.
The C means to read and compare, so because we are trying to read the device name we have to first write to device address AA in firmware mode, register 00, then read and compare what was read back. What is read back has to 42 07 indicating it is a 742 (short for bq27742) other wise you will have a failure.

Next according to the technical reference manual subcommand 0x0002 is needed to read the firmware version. We do the same process of writing to address AA, register 00, then the command 02 00 (little endian for 0x0002). Then you do a read and compare. The returned value has to be 03 01 ( indicating version 103) otherwise you will get a fail.

Like i aforementioned, use bqstudio to create your .fs files to avoid having any errors.

In your case, you have 16 after the "W" indicating you are writing to the device in ROM mode. (address of the device in ROM mode is 0x16)

The line W: 16 64 7A 2E in your case is writing the checksum which is always contained in register 64 and 65. Register 66 tells you the status if the what you wrote was successful that is why you have the line C: 16 66 00. if you have any value other than 00 in the 66 register, you will not have successful programming. So the lines C 16 66 00 is a comapare and check system to ensure what you are writing to the gauge is successfully written. ( you are reading from the device address 16 (address of the gauge in ROM mode) , register 66 and comparing the results of what you read to 00. What you read and compare must be the same otherwise programming fails).

As long as you obtain your .fs file using bqstudio, i would say don't worry too much about what the gauge is doing at each point in the command flow. It is basically a hex dump.

I hope this helps

thanks
Onyx

I have used bqstudio to generate the golden file and in using it have caused the bq27510G3 chip be bricked. The first 12 commands in the golden file appeared to work including several write-read-compare sequences,  but the following read-compare command failed! 

C: 16 04 93 2D 8D D3

Instead of getting 93 2D 8D D3 I get all zeros. From then on the chip appears to be bricked.  What is this command checking for?

When I send the commands to execute flash code as shown below the chip does not switch back.

;--------------------------------------------------------
;Execute Flash Code
;--------------------------------------------------------
W: 16 00 0F
W: 16 64 0F 00
X: 4000

Any read or Write with slave address  0xAA fails with an I2c bus error and any read using 0x16 also results in an I2c buss error. Writes using 0x16 do not indicate a failure but I do not think they do anything on the chip. 

What strategy  should be used if the golden file upload process fails as it has in my case? 

Do you retry the failed command X number of times? Rerun from the beginning of the ROM mode commands or attempt to switch out to execute flash code?

At this point I am not to trusting in the golden file contents as generated by bqstudio Version : 1.3.42 for bq2710G3 yet I need this to work reliably as we head towards production.

See my recent Post about this issue.  "bq27510G3 bricked after attempting golden file upload".

 

 

hi Gerry,
It appears our tool has an issue with the dffs it generates for this device. I tried doing this on my board and my chip got bricked as well. I will draw our tools team attention to this. In the meanwhile use the bq.fs bqstudio creates instead of the df.fs. The bqfs files contains the IF and DF. I verified that works well.

thanks
Onyx

Onyx,

Thanks for verifying the issue. I will give the bq.fs file a try.

Hi Gerry,
Working with our tools team on this issue, they are not able to reproduce this. I am unable to reproduce it again like i did before. The same file that bricked one of my boards is able to program on another successfully. Can you send me the dffs file which you are using?

thanks
Onyx

Hello

i would like to take the occasion of this thread to ask some questions.
For an old project, never arrived to the end, I was working with the bq27500. We went through the different steps of calibration and we created
our GOLDEN file, With flashstream we generated our .dffs file, but unfortunately the project was closed.
Now we resumed it and I still have some question:

1- i see bq27500 it's not suggested for new design, but it should be better the bq27510. The last version of Battery Managment Studio in any case does not support bq27550 but recognize my bq27500 EVM as bq27510, the question is should i change my IC or should just update the firmware?

2- in the case i have to change the IC to bq27510, can i still use the old .dffs file or i need to go once again to calibrate the gage?

3- finally i take the occasion to clarify some doubts, in the .dffs file I have some obscure points:
W: 16 00 01
W: 16 01 00 00
W: 16 03 05
W: 16 04 54 54 15
W: 16 64 C3 00
X: 2
C: 16 66 00

i can't really understand the command highlighted in red, i know it's a write command but on which register? and the data "05" what does?

- in the file generated by flashstream it's missing the part related to firmware version and to unseal the device, the following has been taken from an example file  provided by TI.
;--------------------------------------------------------
;Verify Existing Firmware Version
;--------------------------------------------------------
W: AA 00 01 00
C: AA 00 41 05
W: AA 00 02 00
C: AA 00 24 02
;--------------------------------------------------------
;Unseal device
;--------------------------------------------------------
W: AA 00 14 04
W: AA 00 72 36
W: AA 00 FF FF
W: AA 00 FF FF
X: 1000

May i use this part of code also for my IC? Otherwise how can i generate it?
Sorry for the long post, hope someone can help.
Thank you and regards

Hi Suzumebaki

1. I recommend you change your ic to the bq27510 or the bq27520. These contain the latest update to the impedance track algorithm. Also our latest tool bqstudio does not support older legacy device so i will strongly encourage you to use either of these two recs.

2. no you can't. You need to create a new dffs for the device you decide to use.

3. pls refer to slua541 downloadable from ti.com

4. If you use the '510 or '520 bqstudio which is our new tool will extract the dffs or bqfs file for you and it will contain those sections.

thanks

Onyx

Hello Onyx 

thank you for your answer, unfortunately is what I expected.

I will change the chip but I don't find cost effective the need to repeat the calibration procedure just for the update of the IC.

Thanks again

Hi Suzumemabaki,

I apologize that you have to performe the learning cycle procedure again but it is a necessary step to ensure the chip performs good. Since you have done this before it should be a straight forward process and will just take about a day. i have attached an app note to guide you through the learning cycle process..

6087.LearningCycleOverview_.pdf

thanks

Onyx

Hi Onyx,

Currently I output the df.fs file from my bq34z100-G1 and read the file,would you help me to check if my understanding(my comments at the right side of each row) is correct? thx.

(1)W: AA 00 00 0F     ;target address 0xAA,target register starting from 0x00,written data:0F 00(means write 0x00 to Add 0x00 and 0x0F to Add 0x01)
(2)X: 1000                 ; wait 1000 msec
(3)W: 16 00 03 00 00 ;target address is 0x16, target register starting from 0x00, writeen data 00(@0x00) 00(@0x01) 03(@0x02)
(4)W: 16 64 03 00
(5)X: 20
(6)C: 16 66 00            ;read data, target address:0x16, because it's in ROM mode, target register 0x66, check if the data read is 0x00
(7)W: 16 00 02 00 00 00 EA FF 33 B1 FA 33 6C FB 33 95 FE 33 AD FE 33 FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F 16 00 3F 58 CB 33 C3 00 08 11 00 00 00 00 00 FF AA 0E FB A7 0E FF A6 0E FF A1 0E FF A0 0E FE A3 0E 61 A2 0E DE FF 3A 65 FF 3A E2 FF 33 FF AF 0E        ; read data, target address:0x16,target register starting from 0x00, data to be written: 0x02 0x00........0x0E(does it  overwrite the contents of step(3)?)