BQ78350-R1: host controller seems to be dead after months of it working.

Hi JP,

Do you have the ability to communicate with the AFE and the bq78350 independently? It would be good to read the SYS_STAT register on the bq76930 to understand why the ALERT pin is being driven high. It is possible that nothing is wrong with the bq76930 (for example if it is just the CC_READY bit alerted that the coulomb counter is ready to report a reading).

For the bq78350, it would be good to see if communication is possible. If you can output the flash to an .srec file, we can see if anything has been corrupted and rule that out as a possibility if it reads back correctly.

Regards,
Matt

Hi Matt, 

Thanks for the reply. I was thinking the same about the ALERT pin... that it's "waiting" for a response and never gets it. I can attempt to communicate with it, but it will take modifications to remove the controller from the bus.

How would I go about outputting the flash?

So far I'm unable to do anything with the controller... including connect to bqstudio.

Thanks again, Matt.

JP

Hi JP,

If you're unable to communicate with the controller with bqStudio, it may be difficult to export the flash contents. I assume the bq78350 is forcing the SMBUS lines high? In bqStudio, some devices have a Golden Image plugin that will export an .srec file, but I am not sure if the plugin is available for the bq78350.

It is also possible the device is damaged. I would suggest an ABA swap (test a new device on the failing board and test the failing device on a good board) to completely rule out other factors.

What is the total quantity of devices you have used and is this the only device showing this issue?

Thanks,
Matt

Hi Matt,
The SMBUS lines seem to have activity on it. Unfortunately, I can't even connect to bqstudio to grab the srec. I can attempt to do the swap and see if we can pin point the bad device. However, it is important we find out why the damaged was caused because if it's caused in flight, it will be a catastrophic failure. Can we send back the damaged chip for diagnosis if found?

Thanks Matt,
JP

JP,

It is good that the SMBUS lines have activity. Can you maybe move the bad device to an EVM to see if you can connect to bqStudio? The observations you make during the swap will be very helpful to diagnose the problem.

Here is the link for returning a device for analysis. www.ti.com/.../customer-returns.html Try to provide as much information in the form as you can because this will really help to reach a successful root cause conclusion. Be sure to include the fail rate (one device out of how many?) the .gg file you used, your application schematic, your method for writing to the flash, and anything else you think might provide important clues.

Thanks,
Matt

Hi Matt,
Thanks for the quick responses. I can try to put it on to an EVM and see if I can connect. I'll start filling the form out and include the info that you requested Including the data that I received. Just removed the bq78350 and replaced it with a new one and the board now works fine. We are going to install the "damaged" one on the EVM board to see what happens. 

I'm also having some troubling finding the form with the link you sent. I searched for it on the site and found this: http://www.ti.com/lit/ml/sprabz9a/sprabz9a.pdf

Can you confirm if this is the correct form I'd need to use and if so can you direct me to the department that can assist me with filling out this form?

Update: We installed the damaged ic on the EVM and the board is exhibiting the same malfunction as our PCB.

Thank you,

JP

Hi Matt,
Any updates on this post?

Thanks,
JP

I'm sorry JP. I missed the question when I read your last message yesterday.

Yes, that is the correct form. I am sending you a PM with the shipping address now.

Thanks!

Matt

Hi Matt,

Thanks for the info. Right now the IC is on the EVM, should I do any testing? Should I just send the EVM. Should I try to remove the IC and send it alone?

Thanks, Matt.

JP