BQ28Z610: Help cannot communicate anymore over I2C or SMB ...

Hello Walter, thanks for reply.

Wyatt Keller said:

If you were able to flash other devices successfully the error was most likely hardware or connections related. make sure all the connections are secure and there is stable power during the flash writes.

Yes, you got after to have flashed many boards with my tool, I tested in a production tool, but it did not have problem in communication, a thousands of boards were setup by it. I guess I had a problem with the USB port of the PC or USB/serial cable .... fact is that the update SW stopped and I had to stop the operation, leaving the IC in ROM mode but with the ROM half written... What I do not know is if the BQ28Z610 could be able to recover any operation due not complete ROM flash....  

Wyatt Keller said:

You can try to send the reset command (0x0041) using the advanced communication terminal to see if you can reset the gauge, but the gauge may be bricked if there was an issue during the flash.

I have tried by the bqStudio, with no effect than "no acknowledge" replies at any attempts I did, Now I'm gonna try to use the on-boards PIC to send command directly .... 

That my question was for: what happen at a BQ28Z610 whose flashing operation did not end? There is a method to recover it and restart the flashing? 

Thanks again, Walter and to anyone who will be able to help me.

Maurizio

Yes, Walter I did both mode.

In any case, having a look to the SMBD and SMBC lines, I can see some activities: the BQ28Z610 replies if addressed at 0x16. Particularly, reading the 0x0d register I have noticed a strange behavior, someone of TI could explain it... 

• the waveform sequence shows that the SMBD data and SMBC lines have some activities
• the 0x16 is sent and BQ acks it
• then 0x0d is sent and BQ sets low the SMBC line for about 25 msec
• after 25 msec, the SMBC is released but the bqStudio sends the STOP sequence (both signals low, then rises SMBC followed by SMBD)
• the bqStudio reply is timeout....

I attach the pictures taken by a scope.  

by my not skilled opinion, it seems that the BQ is not fully died and has some activities: possible there is no way to bring it back to the initial conditions for flashing ROM?

I guess that ROM mode is executing a kind of bootloader, then it should be a way to restart it! Unless such bootloader has been altered during that flash operation not ended ....  if the same feature happens while the firmware upload is done by bqStudio, I simply restart the firmware upload! What the hell has gone wrong?

Forgive me but you can't settle me by saying only that the IC is "bricked".... and also I can't believe at a HW internal fault: how can it be happened? 

thanks for replies which help me to understand and go on!

Mauriziowhole sequence.zip

Hello KK, thanks for reply!

Unfortunately it doesn't work, look below. 

Have you had a look at the waveforms? Are they able to explain anything?

Kang Kang said:

During programming, it is important to make sure the IC does not brown out. Our gauge has built-in protections when we program flash to prevent execution of bad srec programming sequence.

Sure, no one wanna "fry" the IC making strange or stupid things while the ROM is under programming. It was a mistake, not yet sure what about, probably the communication link failed even if the SW has a way to do not send data over I2C if the sequence is not correct. (i.e. the address is not 0x16). What i am sure is that power supply did not fail, it was disconnected after a while the programming was stopped at this line of the .bq.fs file "W: 16 05 12 40 00 25 CF 00 26 4A 48 9F 6E 00 24 88 02 25 88 02 9F".

The SW has also protections to do not send on the I2C sequences not completed!

Kang Kang said:

You could try to re-program the entire fs file if it is still in ROM mode to see if this recovers.

Hello KK,

to be honest, I had guessed the same then I did already what you are suggesting. Look:

the BQ is interfaced by a PIC which link the serial protocol from PC to the I2C of the BQ.

I use the original Microchip library for managing the I2C link, while the Main receives serial data, checks the correctness and prepares the messages; it manages also the outcomes of I2C transfer in case MESSAGE_COMPLETE an ACK is sent back to PC, otherwise a NAK is sent. The PC SW retry to send the same row until it receives ACK.

Of course, it cannot be possible infinite wait of the I2C bus, then I added a time out whose result is a NAK sent. the original time out is 30 mseconds, enough long to manage the 36 bytes of the longest reply (MAC block) but, like you've suggested, I changed to 500 mseconds just for trials on this issue.

Indeed, it is not working yet. Do I have to try longer ? It looks odd at me ....

Maurizio

PS: there is no other from TI who can help me on this? If you need waveforms, just asks. here I repeat, I cannot believe that the bootloader was damaged by interrupted upload.... the only possibility remained is that something HW has been damaged i.e. the voltage pump ("When you have eliminated the impossible, whatever remains, however improbable, must be the truth." Sir Arthur Conan Doyle)