Programming DFI to bq20z65-r1

The DFI read/write description in SLUA379 app note applies to z65 (z65 is part of bq20zxx family) as well. 

The 0x800 size of DFI file created by bqEASY is to account for some of the latest devices. For devices that has less than 0x800 data size, bqEASY fill up the remaining DFI file with "0". So for bq20zxx family, using length of 0x700 will work fine. If you have a DFI created by bqEASY, You only need to write up to 0x700 and instead of trying to use the entire DFI file.

The zero padding in my DFI starts at 0x7c0, not 0x700.   And the values read from the chip using SLUA379 look nothing like the DFI contents.

I've made myself an I2C analyser so I can see what the bqeasy software is doing and when I read the DFI file from the chip its reading up to 0x7bf.   It also sends 0xffff to the manu access twice before reading the flash.   If I also do this (not documented in SLUA379) I can read the correct values.

There is also the issue of the first byte read back being the length, this doesn't seem to be documented anywhere.   In the example flash reads in SLUU386 it says you receive 32 bytes, actually you get 34.   The first byte being length (0x20) and the last being the checksum.

I'm finding more and more things that don't make sense in the app notes.

SLUA379b page 3 Reading and Saving the Data Flash Image From the Golden Pack:

'// FOR CLARITY, WITHOUT USING CONSTANTS

'// 0x700 is the data flash size.

0x700 \ 32 = 56 rows

iNumberOfRows = &H700 \ 32

Page 4 Writing the Data Flash Image to Each Target Device:

 '// FOR CLARITY, WITHOUT USING CONSTANTS

iNumberOfRows = &H60 \ 32 '54 Rows

Firstly 0x60 \ 32 does not equal 54, its 3.   Secondly why read 56 rows and only write 54?

There seem to be some major issues with the documentation.

Again using my I2c analyser I can see that bqeasy is using a very different sequence to write the DFI into the device.

So far I've managed to render just 2 devices unusable.

There is a typo is the application note:

"iNumberOfRows = &H60 \ 32 '54 Rows" should be "iNumberOfRows = &H6C0 \ 32 '54 Rows"

The total flash size is more then 0x700. The discrepancy in row # is because the last few rows are used for temperate data, like a scratch pad, which don't really need to be saved as part of the golden image. Nevertheless, I agree we should make sure the row # is consistent in the read/write routines and we'll update the app note ASAP.

As for bqEASY, we recently updated the code to cover the entire data flash size which include the temperate data rows and avoided to use a hard code row#. This is the reason when you look at the DFI file, it has data more than 0x700 data.

0xFFFF to MAC is not a valid command. bqEASY is doing that only because it has something with EV2300. This line of code is removed from the document because customer using this document is using their own communication interface. And we don't see the need to send 0xFFFF to MAC because, again, it is not a valid command to the device.

Finally had a chance to get back on this project.   I can get it to program the flash but the first 10 rows don't match my dfi file.   The device can be put into impedance track mode and runs but the correct sense resistor value has not been set.   My board uses 20mOhm as my currents are not that high.

I can't see any mention of the sense resistor in the data flash section of SLUU386.

Also is there any direct relation between the table in C.14 of SLUU386 and the actual contents of the dfi file?   Can you use the subsclass ID and the offset to find the value in the dfi file?

Ta,

How did you verify the first 10 rows don't match with what you programmed? You can perform a read verify after programming the DFI while the device is still in ROM mode. If you put the device back to FW mode, some data flash locations maybe updated by the FW.

You can use extended command 0x71 to read the sense resistor value (return in uohm).

No, the subclass IDs and offsets are FW addresses. They do not reflect the actual physical data flash location.

I used the read function as detailed in slua379.   It shows that the first 10 rows of 32 bytes different to the DFI file.   If I used BQeasy to program the chip it would read back identical contents to the dfi file.

I would have thought that the sense resistor value would be in flash.

Everything seems to be working! 

The read function in the app note is what bqEASY use as well. Make sure you did not switch back to FW mode between write and read verify.

It still seems to be hit and miss.   Sometimes when I read back I get all 0xff and the chip stops responding.

These devices seem to be very fragile unless you are using bqeasy.   But from my investigations bqeasy doesn't do things the same way as shown in slua379.