BQ78350: PF data flash wearout failure

Thanks for the quick reply Onyx!

Hello Onyx,

Clearing the wearout PF does not work by sending these two commands, one after the other. I tried both ManufacturerAccess() and ManufacturerBlockAccess(). Have I misunderstood what you meant to do?

Also, I've caused the same failure on another brand new part by writing the dataflash (2k bytes 0x4000 - 0x4799) that was read out from a golden device. Is this not a valid thing to do? We need to program these chips in system and can't use the EV2300 or bqstudio to do it, so selectively picking just what needs to be written in our software register-by-register is onerous.

Thanks for your help,

Kurt

Hi Kurt,
The command need to be send really quickly one right after the other. Also, they need to be sent in little endian format.

For programming the bq78350, you will want to consider our tool bqproduction. You could also use the hex dump functionality of bqstudio and follow the app note below. Although written for a different device should be applicable.

www.ti.com/.../slua743

thanks
Onyx

Thanks Onyx,

I'll review that documentation for the production programming.

I'm still having trouble with those recovery commands. I also tried to issue a reset after sending the commands but that didn't help. Here's the trace of what's going out, the commands are only separated by 1.3 ms now:

Hi Kurt,
My apologies, that command was for our older bq20z devivces. Since the unseal and FAS commands never changed for our legacy devices, i assumed, the pf clear remained the same. I looked through the code and saw that the command is a mac access command 0x0029. It is actually in the TRM and it is called permanent fail data reset.... the names our FW developers give these things ha! That being said, try that and see if it clears the pf flag.

thanks
Onyx

I did see this command, but it doesn't have an affect on the DFW status (at least not on its own). Consistent with 4.18 of the TRM after this flag pops up I can't write to the data flash anymore, so my ability to simply restore the original values from the flash is also lost. Is there anything else that can be done?

Hi Kurt,
So are you saying it doesn't clear the DFW PF flag? Are you able to extract an srec from the gauge?
thanks
Onyx

I'm having some trouble dumping the SREC using bqstudio 1.3.54.1. This part is on a different SMBUS address than the default (7/8-bit 0x9/0x12 instead of the default 0xb/0x17), changed via hardware I2c address translator. I can see bqstudio properly sending the ROM mode command 0x0f00 to 0x9/0x12, but then it looks for an ack on 0xb/0x17 and fails there. If I were to put the part into ROM mode with my own software, I might be able to dump the srec with a description of how that is done. Is that documented anywhere?

Edit: and yes I am saying that 0x0029 doesn't clear the DFW PF flag.

Hi Kurt,
Can you use the advanced smbus comm window of bqstudio to send the command and then send a snap shot of the commands sent and the bqstudio registers. Command 0x0f00 puts the device into rom mode and you should be able to send that with your software but i don't have any document on how to extract the srec. Are you unable to change the address of the gauge to the default value so bqstudo can extract it?
thanks
Onyx

I was able to DFW another device by the same method, but this time on the default address, with the same results. Attached is the srec from that part.

bq78350_r1-dfw.srec.zip

Edit: I should also add, that if I re-flash the firmware from the srec of a good part, I can recover from this failure. But this isn't an option for my parts that are on the alternate I2C address.

Hi Kurt.

To clarify, Does this DFW issue occurs only when you try programming a device having a different address from the default? if you are able to program a board having the dfw write issue with a good srec, why doesn't this issue occur when programming those devices?

thanks
Onyx

The DFW issue occurs when I try to write the whole 2k dataflash of a device, address doesn't matter.

It turns out that if I write only 1568 bytes (0x620), which is what the hex dump in bqstudio produces, and I no longer see the DFW. So that solves the first part of my question.

But I'm still left with a few devices on the alternate address that got DFW'd, which I'd like to be able to recover if possible. I can't recover these ones by writing the SREC the way I recovered ones on the standard address.

when you write a good srec extracted from a good device, do you get the dfw issue? is it possible to change those to the default address and try recovering them with a good srec.
thanks
Onyx

If I write the srec that came from a good device, the DFW issue does not occur, and it would clear a DFW that is present.

I am hoping to not have to modify the hardware for my remaining DFW devices to recover them, but it sounds like we might be running out of options. Unless there is documentation for writing the srec, some other way to write the srec on devices besides bqstudio (or a fix to bqstudio), or some other remedy besides the srec.

Hi Kurt,
You can write code to program the srec on your device. The srec is a standard motorolla format. Did you ever attach your srec with the DFW issue on here. I had wanted to try to see why the PF reset command doesn't work and i need to see the failure on a board to be able to try and see why the command doesn't work
thanks
Onyx

Great, thanks I'll look into that.

The SREC from the device with DFW is in the post from Oct 6, 2017 10:58: e2e.ti.com/.../2325269

Kurt