bq27510 Firmware version check and programming using dffs

Hi Kat,

You should be checking FW_VERSION before entering ROM mode.

Are you using both G2 and G3 ICs in your production line, and programming the corresponding G2 or G3 dffs file?

Note that you could use bqfs to upgrade G2 ICs to G3 FW.  Then all would have the latest version.

I'm sorry we don't yet have a change list for 510-G2 to G3.  It's not quite a linear change.  The code-base for 510-G3 was actually 520-G4 since the 510-G2 was so old.  We are still working on the best way to communicate the changes.  However, the 520-G3 to G4 changelist will apply somewhat here.  I will mention that the register mapping (DataRAM) has changed, so keep that in mind.  You need to use different addresses to read SOC depending on whether you are using G2 or G3.  Brilliant...

You can also generate the dffs file with the FW_VERSION command built in.  If you use the command-line Flashstream.exe, do this:

DOS> flashstream.exe bq27510-G2_golden1.senc -checkversion:10050004 -gotorom -comments

You will see the FW_VERSION command being sent and then some compare lines to check the version returned at the beginning.  This is all done in FW mode and not ROM mode.  Then you will see the unseal sequence and the go to ROM sequence.  This means you won't have to hard-code it.  Or you can strip out those lines and hard code it if you want.

The simplest approach might just be to blindly program G3 bqfs files on all ICs.  Then it doesn't matter whether they started as G2 or G3 and you need no logic at all.  You will be wasting a little extra time to program the instruction flash of the G3 when it wasn't really necessary, but it's the most foolproof method that some choose to use.

dMax,

We had opted the use of bqfs before but it takes almost 1 minute to program the Fuel Gauge. The option we have to lessen the time it takes to program the fuel gauge is to check the firmware version and then based from returned values, we will program the fuel gauge with G2_dffs or G3_dffs. 

The -checkversion:10050004 will have these following lines appended in the dffs:

W: AA 00 01 00
C: AA 00 10 05
W: AA 00 02 00
C: AA 00 00 04
W: AA 00 14 04
W: AA 00 72 36
W: AA 00 FF FF
W: AA 00 FF FF
X: 1000
W: AA 00 00 0F
X: 1000

The command C: AA 00 00 04 verifies unit is G3 if the read values are correct. what is the expected value if firmware is G2?

In addition, we had tried programming the G2 with the dffs but the Data Flash values did not changed. We had programmed the G2 in similar algorithm we had used in programming bqfs. (Enter ROM Mode -> Read and Execute commands in the dffs file which includes Exit ROM Mode) Are there any additional methods needed to be executed in programming the fuel gauge using dffs?

Thanks in advance

Kat

bq27510-G2 is FW version 1.23

bq27510-G3 is FW version 4.00

For G2 you would use -checkversion:10052301

There should be nothing different between programming the dffs and bqfs, but if you put the -checkversion and -gotorom options in there then you should not hard-code going to ROM since the first lines of the file will be expecting to talk to the IC at I2C device address AA instead of 16.

Also, can you confirm that your flashstream programming code will fail if it reads different values for the C: (compare) lines?  You should not continue to subsequent lines if the readback and compare data does not match.

dMax.

Thank you for your reply.

Regarding the Compare (C:) command lines, we have a checking algorithm wherein if the compared data returns false, the system will stop the operation (including Exit ROM Mode) and retry again from the very beginning (Starts with Enter ROM Mode). we allowed the system to do this up to 10 retries.

This is the same algorithm we used for bqfs and dffs programming. However, when we programmed using the dffs, there were no changes in the Data Flash Image. In addition, the Fuel Gauge seems to have been bricked as it had not responded to bqfs programming and dfi/senc programming using the EV2300. Please note that the Fuel gauge was functional before it is programmed with dffs.

Which is why we are wondering what could have happened or what are the things that could have triggered this.

Thanks,

Kat

If it's bricked then this is typically caused when a dffs (or dfi) is programmed onto an IC with an incompatible FW version.  For example, if you programmed your G2 dffs file onto an IC with G3 FW.

The only other way I can think to brick it is if you had failed to detect write errors and proceeded when a C: line failed.  Normally if you stop in the middle of the dffs file and were to power cycle the gauge, for example, the gauge would power up in ROM mode and you could start again from the beginning of your file in ROM mode where you erase the flash and try again.

You said you programmed a dffs file and no changes were seen in the dataflash AND that the IC is bricked.  Can you please clarify?  How were you checking the dataflash?  Using EVSW and a GG file?  How can you read it if the IC is bricked, or did it get bricked later?

If the DF never changed, then I would assume that either the contents of the file were identical to what was already in the IC, or the file was not actually programmed.  Each section of the dffs file is erasing or modifying dataflash step by step, so it's not possible that you could proceed through the file without updating something.  The file is NOT loading stuff to RAM and then waiting for some final command or sequence to actually "commit" it to flash that might be missed.

I'm just trying to think of all possible angles for you, so hopefully this info helps.  If you have more details to share that might give me more ideas, please let us know.

dMax,

we have a G2 senc file and dfi file. we generated bqfs and dffs using flashstream. We used only 1 Fuel Gauge for the entire testing stated below.

We used a Fuel Gauge (G2) with its default values. We programmed a G2 Fuel gauge using the bqfs. The DF values are as we had expected (checked the DF values using the EV2300 and bq EVSW). Then we reprogrammed the Fuel Gauge with the Recommended Golden Image (default dfi for G2). The G2 DF revert back to its original values (values upon purchase of the Fuel Gauge). Then we programmed using the dffs. The return status of our program did not indicate any C: Error (Please note that if an error occurs in C: command, the operation will be stopped and the system will retry the process for 10x starting from the beginning. In addition, if error occurs, "Compare Data Error" appears in the screen.). We checked the Fuel Gauge using the EV2300 and bq EVSW (navigate to Data Flash and click Read All). DF values did not change (values upon purchase of the Fuel Gauge). We retried programming the Fuel Gauge with the dfi and senc file using the EV2300 and the bq EVSW. The values still did not change. We also tried reprogramming the device with the bqfs. The Data Flash values are still incorrect. It does not reflect the DF of the Golden File we had generated.

Thanks,

Kat

Hi Kat,

Are you saying the the bqfs file can update dataflash, but the dffs file appears to leave everything as default values?

If you want to upload all of your files (or send them to me in a direct message), we can take a look at them.  Please include all file formats (bqfs, dffs, dfi, senc, etc.)

dMax, 

Your statement is correct. We can successfully program the fuel gauge using the bqfs but not the dffs. I will forward the files to you.

Thanks in advance

Kat

dMax,

We had programmed the fuel gauge with the desired dfi. Then, we had updated the Manufacturer Block Info and read the data flash values to the senc file. Using the senc file, we had then generated the bqfs and dffs.

This is the syntax we had used in generating the flashstream files:

FlashStream.exe nameofsencfile.senc -psize:32 -keepdf

Does the failed fuel gauge programming using the dffs file be caused by using the -keepdf (preserve current data flash contents)?

However, we had tried programming the Fuel Gauge before with bqfs1(FlashStream.exe nameofsencfile.senc -psize:32) and the DF was not updated. When we programmed the Fuel Gauge with bqfs2(FlashStream.exe nameofsencfile.senc -psize:32) the DF was updated.

Thanks,
Kat

Hi Kat,

Yes, the -keepdf option will make it skip programming of dataflash so you should not use it.

What is the difference between bqfs1 and bqfs2 that you mentioned in the last paragraph?

dMax,

when bqfs1 is generated we had used the command : FlashStream.exe nameofsencfile.senc -psize:32

when bqfs2 was generated we used the command: FlashStream.exe nameofsencfile.senc -psize:32 -keepdf

Thanks,

Kat

Hi Kat,

I sounds like bqfs2 (using -keepdf) should not have updated the DF and bqfs1 should have updated the DF.  Is this what happened, or is it the opposite as your previous post implied?

dMax,

The opposite happened. bqfs2(-keepdf) updated the DF.