BQ20Z45: BQ20Z45 BootROM mode, how to upload firmware/file?

I found a similar issue on this forum concerning the BQ20Z80 and its
'Application Book' (slua380.pdf).
On pages 218 - 220 the required information is given.

Bluntly assuming that there is 'not much difference' (of course there is!)
I just wrote a routine to read the ROM contents from 0x200 and on,
knowing that my friends 'Golden Pack' filesize is 2048 bytes (0x0800).

I get a nice hex dump in 32 byte bursts (max i2c block size) and the
device switches back to normal mode after sending 0x08 to the SMBus.

Promising!

The only thing to figure out is whether start address 0x200 is correct for the BQ20Z45.

If anyone can confirm this, or has the proper address, I'll tick 'This resolved my issue' ; -)

Ok, good and bad news ...

The good news is I found a more appropriate document titled:
"Data Flash Programming and Calibrating the bq20zxx Family of Gas Gauges"
(slua379e.pdf), written by TI-employee Jackie Hui (whose name I saw in some posts on this forum!)

So the first good news is, is there is at least somebody here exactly and fully 'in charge' of the matter!
(fingers crossed he reads this thread ; -)

Second good news is that my assumption concerning the 'offset address' (I mistakenly wrote 'ROM contents' ...) (0x0200) for the BQ20Z45 was ok, albeit (at the time of writing of my previous posting) I got the value from a BQ20Z80 document.
In fact the flash address is 0x0200 << 5 , thus starting at 0x4000.
Anyway ... I'm able to succesfully read the flash contents.

In the aforementioned document it appears that the 'flash size' is 0x0700 bytes,
instead of 0x0800 (which is the length of the 'Golden File' my friend uploads to all his refurbished packs first and subsequently alters the variables matching his new batteries. His packs work very well ... interesting ...)

The bad news is that I almost certainly bricked a BMS in one of my test packs. Almost 100% sure this is due to (certainly my interpretation and/or in my opinion) (ambiguous) information in documents slua380 and slua379e.
If I'm incorrect, please correct me ; -)

slua380 p220 describes how flash can be uploaded to the BMS.
Basically the 'flash file' is chunked into 32 byte blocks. After putting the BMS into BootROM mode the appropriate 32 byte block/chunk inside the BMS is erased and subsequently programmed.
This repeats until the end of the flash file is completely uploaded.

However, after reading slua379e (and assuming that this document is more relevant because it's more recent) things became confusing to me.

slua379e p4 describes how to upload a flash file to a bq20zxx.

What confused/s me is the following:

Dim yDataFlashImage(&H700) As Byte <-- seemingly compliant with slua380

*snip*

'// FOR CLARITY, WITHOUT USING CONSTANTS
iNumberOfRows = &H60 \ 32 '54 Rows <-- not 0x0700 and 0x60 / 32 is not 54 (?)

*snip*

'// ERASE DATA FLASH, ROWS ARE ERASED IN PAIRS <-- pairs ?
For iRow = 0 To iNumberOfRows - 1 Step 2
1Error = WriteSMBusInteger (&H11, iRow) <-- what is written to 0x11? (0x00iRow or 0x[iRow+1,iRow] ?)
DoDelay 0.04
Next iRow

(yes, I am not into VB at all ; -)

Because I interpreted the WriteSMBusInteger (&H11, iRow) routine as a routine which writes a (16 bits) word to 0x11 I wrote 0x[iRow+1,iRow] to 0x11, being:
word = iRow | (iRow+1) << 8 ;

Well, that (100% certainly) was my fatal mistake ... ?

So, what to write exactly to the device in order not to brick another pack?

PS. I am just into the BMS world for a week and want to help my friend.

For those interested, this is my working flash_read & hexdump routine:

@Batt: thanks for your sign of life (... and (moral) support) ! \o/

I'm not into discussions about what is 'a manufacturer' or ... not (maybe a '(re)manufacturing refurbisher' ?)

I'm asking questions concerning TI's documents and how to interpret 'information' in these documents.

Gateway of the last resort is sniffing the i2c/SM-bus to find out what (really) happens.

@Batt: thanks for neither 'acking' or 'nacking' my musings. At least I know someone is sniffing me ; -)

Concerning 'hardware sniffing', my friend uses a working (albeit very cumbersome) procedure to
'manufacture' his packs. So, a few days ago, prior to my 'membership' here, I already took the mental
junction to sniff the bus before he uploads his 'Golden File' into his battery packs. My hope was that
posting my questions here would facilitate my journey, i.e. not going into the hazzle of sniffing.

PS I reckon when I succeed I'm not allowed to post the solution here?

Btw, I discovered each time I download flash/fw-contents
(or perhaps the device is put into BootROM mode?),
the 'partial reset' counter (ResetData, 0x57) is increased by one.
Is this nominal?

Bratt, can you / are you allowed to comment/elaborate on the picture below?

My question: Is the information on p85 and p86 of sluaa313a CORRECT in

the following senses:

1. the absolute values of the slave address(es), being 0x16 and/or 0x17 ?

2. that one has to deliberately use a slave address which is +1 higher for some operations ?

In other words, my BQ20Z45 pack uses 0X0B as slave address, does this mean when the

information in the picture is CORRECT I've to write to a slave address (0x0B + 1 = 0X0C) which is

non-detectable using a normal i2c_start-condition?

Or ... is the information on p85 and p86 wrong?

I received a message from 'Igor', but when I click on it I can't see it here, but I received a copy via email as well.

@Igor: your message is crystal clear to me, as I already posted myself concerning the 'definition' of
I2C-addresses. Before this project I didn't dive too much into I2C, but now I had to. People saying that
I2C is a 'simple' protocol are -in my opinion- wrong. When you've to strip down the protocol down to logic
levels and timings, it's not 'so simple'. (RS232 or SPI is easier ; -)

When I was confronted with semantic discussions concerning how to interpret 'I2C addresses' and how to
communicate this / write this down, it's a confirmation for me that the protocol is not 'so simple'.

Reading the 'formal' documents about I2C one speaks of 7-bit 'addresses' (there is also a 10-bit mode, but
I leave that out here). For whatever reason this 'address' has to be shifted left to obtain the 'real address'
where the LSB indicaties a read or write option. This is a choice. . . but why did Philips (and mind you, I am
from The Netherlands, Philips is a Dutch company ; -) not decide to leave the 'address' alone and use the
MSB (7th bit) to indicate a read or write operation? (to mention another perspective ; -)

In short (sorry Batt I am NOT into bashing your employer nor the hospitality of this forum), when one writes:

"SMB slave address (0x16)"

*snip*

"SMB slave address (0x17)"

this is in my opinion de facto confusing. It should read / be written as (for example):

C 1.4 Example
7-bit I2C addresses are shifted left one position. The SMBus address 0X0B therefore
should appear as 0X16 on the I2C-bus.

*snip*

"Address the device"

*snip*

"Address the device with read bit set"

Anyway . . .

The incentive of this thread was that I was not able to alter flash contents (SubClasses and Offsets etc).
Giving information on this to non 'manufacturers' appears to rub with policy issues.

Using a different way than described in the datasheet / technical reference document
I am now able to alter desired flash contents, so I solved my own issue ; -)

Bravo, and congratulations! Thank you Remco.