Despite my hesitation regarding a previous instance of bqWizard destroying a BQ78PL116 device (I posted about it here a few months ago) we decided to go ahead and build our new board around this device. I assumed that because so many other folk were successfully using this software, it must be just a minor glitch, and I was for the most part able to use it with the eval board aside from that one event.
Now I am regretting this. I have today seen bqWizard destroy two '116's, on two different boards (of the three we had made for the rev 1 run; the third had a faulty PCB).
Basically, therefore, it destroyed both of the working boards I had available to me. While we can of course remove the chip and put another one on, it's a fiddly procedure which costs our company money in both the price of the chip (not extravagant, but still $, particularly as I have to import them) and more particularly our time in doing so (which is the real cost). And of course, there's no point in reworking them if it's just going to happen again, which seems likely given the above experience.
It also obliges me to inform our customer (for whom we have designed this board) that I cannot guarantee that they won't suffer the same fate if they go into full production, given it's their responsibility to program the devices.
Surely, TI, you can do better than this? You have what pretty clearly seems to be shoddy software that has the capability to destroy your hardware, and yet you REQUIRE us to use this software (or the API it is based on) to set the devices up! It is unacceptable that a crash in your software should irretrievably lock the chip.
Surely, surely, there is a way to recover it? I have had you tell me before that the answer is "no; there's no way to unseal it", but this just seems insane. The chip's firmware sees an inconsistency in its stored data, and its response is to say "meh, I give up, replace me?!"
At this point I am really really regretting recommending TI to my customers; it was my decision to point them at this chip and it really looks like I'm going to have a lot of egg on my face if I can't resolve this. There is simply no way I can say to them that they should go ahead and build 5,000 or 10,000 of these if I can't be confident in the procedure to configure the devices.
TI, please address this issue with your software; either change it so it doesn't crash, or if that's too hard make it so that when it does crash it doesn't seal the device! Or if even that is too hard for your expert software engineers, tell us, your customers, how to unseal the chip when the preceding events occur! I am sure that if you really wanted to, you could find out from your firmware engineers how to do this.
I'll attach the screenshots I took today of the crash. Both crashes were identical; they occurred when I tried to load the pack configuration onto the BQ on the newly-built boards.
The crash (keep in mind this happened twice on two different boards).
(I have no idea what modal form the message refers to; as far as I can tell no other dialog
was open and I took particular care the second time around to ensure nothing was amiss).
This is what it says when I click 'ok' after the run-time error.
When I click 'ok' again, I get the 'bqWizard has stopped working' message.
When I re-start bqWizard, the device is sealed. Time to schedule the board for re-work. Thanks TI!
