• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 192 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

BQ78350-R1: Permanent Fail IFC Flag

BQ78350-R1: IFC Error at Single Product with BQ78350_R1_v1.04 Firmware

Berk KARADAYILMAZ
Prodigy 50 points
Part Number: BQ78350-R1
Other Parts Discussed in Thread: BQ78350

Tool/software:

Dear TI Team, 

We have been notified of existance of a IFC(Instruction Flash Checksum Failure ) in one of our e-bike product after a couple of usage in the field. This is the first time we faced with this failure , which is seen only at one product. 

Upon this failure I have checked the following e2e threads from the forum. 

When I inspected the responses given to threads mentioned above , I saw that there has been an improvement in instruction flash checksum calculation in R2 gauge firmware. This change is cited from "bq78350-R1 TRM Addendum for the bq78350-R2 Device" at given responses.  Before taking any action on devices at the field,  we would like to take information about following questions. 

  • Has IFC failure seen randomly at  BQ78350 products with R1 firmware? Is there any scenario that triggers IFC error more frequently besides reasons mentioned in previous threads?
  • Is there a possibility for IFC error to occur at ideal implementation later? Could we ensure that IFC error will not occur in a product that has been used within defined limits with R1 firmware?
  • Had IFC error seen in devices with R2 firmware given they operate within defined conditions? Will R2 gauge firmware update provide a certain solution to IFC error?

Information about Gauge IC , system status and logs taken from faulty system is listed below. This logs are read from Gauge IC by E-bike battery MCU and formatted accordingly.  

Gauge Hardware : Bq78350_R1

Gauge Firmware Version : bq78350_R1_v1_04_build_26 1.srec

Permanent Failure

0x10000

Protection

0

Cell1 Voltage

3917

Cell2 Voltage

3913

Cell3 Voltage

3919

Cell4 Voltage

3921

Cell5 Voltage

3922

Cell6 Voltage

3911

Cell7 Voltage

3919

Cell8 Voltage

3917

Cell9 Voltage

3916

Cell10 Voltage

3907

Max Cell Temperature

19

Min Cell Temperature

8

FET temperature

8

Current at PF

0

Remaining Capacity

0

Full Capacity

9000

 

We would appreciate a fast response for our diagnosis , planning and informing  processes. Thank you for your interest. 

  • 0
    TI__Mastermind 27321 points

    Hello,

    The IFC failure in the BQ78350-R1 is not entirely random but is often tied to underlying issues with the flash memory or firmware execution. Based on my knowledge of BMS systems and the BQ78350, the IFC failure typically occurs when the gauge detects a mismatch in the instruction flash checksum, which can happen due to Flash Memory Wearout, Power Supply Issues while flashing the device, Electromagnetic Interference (EMI) can interfere with flash operations, leading to corruption.
    Even in an ideal implementation (i.e., operating within specified voltage, temperature, and current limits), the IFC error can still occur.
    The BQ78350-R2 firmware includes improvements to the instruction flash checksum calculation, as noted in the "bq78350-R1 TRM Addendum for the bq78350-R2 Device." These improvements were specifically made to address issues like the IFC failure seen in R1. Based on my knowledge, the R2 firmware significantly reduces the likelihood of IFC errors by:
    • Improving the robustness of the checksum algorithm.
    • Enhancing error detection and recovery mechanisms to prevent false positives.
    • Better handling of edge cases like power interruptions during flash operations.

    Upgrading to the R2 firmware will not provide a 100% certain solution, but it will significantly reduce the likelihood of IFC errors. The improvements in R2 address the known firmware-related causes of IFC in R1, such as checksum calculation issues. However, if the IFC in your device was caused by a hardware issue (e.g., flash memory defect) or an external factor (e.g., EMI), the R2 firmware might not fully prevent recurrence. That said, given that your logs show normal operating conditions and no other PF flags (like DFW), the R2 firmware is likely to resolve the issue in your case.



  • 0 in reply to Jose Couso
    Prodigy 50 points

    Dear Mr.Couso

    Thank you for your response. We had an opportunity to read written gauge firmware on the faulty device. It seems that some part of the gauge firmware is deleted and 3 bytes from random location of firmare does not match with the original firmware (bq78350_R1_v1_04_build_26 1.srec provided at the TI web page). 

    From my analysis R1 firmware did not indicated a false positive in this case. 

    - Will R2 gauge firmware solve this specific case?   

    - What will be the possible cause of this error? Is there any recommendation for the cause of the problem? 

    - Is there any other parameter that you suggest us to look for or provide to you ? 

    In couple of days we will have opportunity to have faulty product delivered to our office for further physical investigation. In the meantime we would like to plan for futher analysis and inform our customer about the situation. 

    I can provide the read .srec file from direct messaging as I suspect that some of the configuration parameters set by us are also read by the firmware read operation.

    Thank you for your assistance.       

  • 0 in reply to Berk KARADAYILMAZ
    TI__Mastermind 27321 points

    Hello,

    1- No, R2 firmware won’t directly solve this case because the IFC was caused by actual firmware corruption (deleted sections and mismatched bytes), likely due to a hardware or environmental issue (e.g., flash defect, EMI, power supply issues). R2 improves checksum handling but cannot prevent recurrence if the root cause is hardware-related. Reflashing with R2 on a new or verified unit may improve reliability.

    2- Possible causes include: (1) a flash memory hardware defect, (2) power supply issues (e.g., brownouts during flash operations), (3) EMI from the e-bike environment, (4) environmental stress (e.g., temperature, humidity). Recommendations are to test the flash memory for defects, stabilize the power supply, mitigate EMI (e.g., add shielding), review the device’s environmental history, and consider upgrading to R2 after addressing hardware issues.

    3- Suggested parameters to investigate are historical data (lifetime logs for temperature/voltage extremes), power cycle count, voltage transients, and EMI exposure. Tests to perform are flash memory integrity test, environmental stress testing, power supply analysis, and physical inspection of the PCB. Providing details about the corrupted .srec file (e.g., addresses of mismatched bytes, deleted sections) could help identify patterns in the corruption.