Programming the golden file

Could anyone please help me on this. Thanks!

Hi,

You'll want to refer to this app note:

http://focus.ti.com/analog/docs/techdocsabstract.tsp?familyId=394&abstractName=slua449c


Basically you need to program the DFI file to the gas gauge, and as far as I can tell, there are two ways to do this:

1) Using the bq software

2) Embed the DFI file into your micro's firmware and write the necessary commands to program the gas gauge if it detects an unprogrammed device.


I opted for #2.  The commands necessary are in that app note, although it's a bit sloppy if you ask me.  Also, be careful when doing the instruction flash erase step...if you don't successfully reprogram the instruction flash afterwards (which has to be read from the device first), you'll brick the gas gauge, at least until you can get a copy of the correct IF data from another identical part (don't ask me how I know this).


As far as embedding the image itself, I linked the DFI file in as a generic binary using the gcc toolchain, so there was no need to get the hex values "out."

Hope this helps.

@Joel, Thanks for the tip. I'll read up what you sent.

I managed to brick one gauge trying to prgram it. It no longer responds to standard commands. There are only 3 flow diagrams in the app note.

@Joel, Do you send instructions on Fig 8(SLUA449C) with standard commands using the Control command.[ 0x00] followed by Data[ 0x00, 0x0F ]

If anyone knows how to recover a bricked gauge, please let me know. I did not reach the erasing of the Instruction Flash section yet. I would appreciate if TI at least provides some pseudo code for programming the gauges.

Thanks.

Hi,

I only send the "enter ROM mode" command using the Control command of [0x00 0x00 0x0F].  Once that is done, the device behaves significantly differently than what is documented in all the other datasheets and app notes.  In fact, I'm pretty sure you can no longer talk to it using the I2C address of 0xAA, but rather 0x16, as noted on the flowchart.  I would have thought a power cycle would restore it to the "normal" 0xAA mode, but maybe not; I don't know if I ever tried that.  In any case, if you haven't actually issued any of the erase or program commands yet, your device should be just fine.

One thing to try is to send the "exit ROM mode" command sequence as shown at the end of Figure 10: [0x00 0x0F], [0x64 0x0F 0x00].  Again, this is using the 0x16 I2C address rather than the 0xAA.  After this command is issued, the normal 0xAA commands should work again.

Joel, Thanks a lot. That helped. It's unlocked now.

Sorry about bugging. But how did you manage to read the 96 bytes after issuing the read command checksum in figure 8? What was the data format.? I was not able to find the "Read" command in the flowchart.

After you send the checksum, you simply read 96 bytes starting at command/address 0x04 (so 0x04 to 0x63).  There isn't a particular format, you should just store the raw data in RAM for reprogramming later (see Figure 10).  You may also want to save a non-volatile copy somehow if you are able, in case there are problems after you've done the IF erase but before you've been able to reprogram it.

Thanks, the code was working, but I wasn't incrementing the address. I stored both the IF  rows in a text file as a backup.

I was trying to write the IF section back( as in figure 10). For some reason my Checksum check(0x66) does not return a 0. When you do the execute the "Write Row" command, do you send the packet in this way:

0x04 byte0 byte 1... byte95. Does the gauge increment the address as data comes in? Thanks for bearing with me.

Yes, I send the packet as one large I2C command with all 96 bytes, starting at address 0x04.  The gauge does increment the address internally for each new byte.

Basically I do:

[0x00 0x02] (program row)

[0x01 <N>] (N = 0 or 1)

[0x02 0x00] (column 0)

[0x04 byte0 byte1 ... byte95] (row N data)

checksum = sum(row N data) + 0x02 + N  (N = 0 or 1, checksum should be a 16-bit int to allow rollover)

[0x64 checksum_lsb checksum_msb] (I use a single write here, even though the flowchart shows separate; it probably doesn't make a difference)

Hope this helps.

Thanks.

And uh-oh. I'm back to square one now. Although, I managed to save all my IF into arrays on your advice and have a soft copy of it. But I think my gauge is officially bricked. I'm just doing the IF flash for now, not the DFI. I was able to do the following once and verify if the IF copied back was the same. When I did it again, the gauge did not respond.

Program flow:

ROM Mode->Copy both rows to arrays -> erase rows -> copy rows back.

I tried using the exit rom commands to get it out of ROM mode, but the gauge doesn't respond. If you have anything on your mind please let me know.

I ordered some some gauges from TI, but they will take some time to solder and setup.

I did something very similar before trying to write the DF.  When I eventually bricked it by erasing the IF without writing the rows back, I was able to recover by:

1) Enter ROM mode (I can't recall if this command actually succeeded or not, if it doesn't just try ignoring it and continuing on)

2) erase IF

3) Write saved IF data rows

4) exit ROM mode

If that fails...you're in uncharted territory as far as my knowledge goes.  Does just not respond to any command?  Not even any of the ROM commands?

Good luck.

No none. I tried sending an exit ROM command and then send the command to go into ROM mode again(with some delay between the two). As for now we are getting the gauges replaced with new ones.

Right now I'm also facing the problem of writing the .dfi file at production... I have recently made a post about that.

I don't know why TI hasn't released documentation about ROM mode. This makes the process of writing the DFI a dificult and error prone process.

I could be great to see msp430 code samples, for instance.

bluehash: One other possible explanation for why your ICs are bricked are that the DF and IF versions don't match.  What I mean is that if you were only upgrading the IF, as you mentioned, but the DF was left for an older version of firmware, the conflict would result in a bricked IC.  For example, if your IC started with bq27510-G1 DF+IF, but then you programmed the IF with bq27510-G2 you would have a bricked IC.

You might also get more useful info from this thread:

http://e2e.ti.com/support/power_management/battery_management/f/180/t/75365.aspx

Thanks dMax.