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.

BQ27520-G4: i2c communication errors and abnormal flag data.

Part Number: BQ27520-G4
Other Parts Discussed in Thread: EV2400, , BQSTUDIO

Hello                                                                          

We have found a problem with a board under development that causes i2c communication errors and abnormal flag data.

This problem occurs in my system and in connection with EV2400.

Communication errors are "No acknowledge from device "and "EV2X00 Adapter USB Timeout"

Other values for Voltage and RemCap may be 0.However, this problem occurs on some boards and not on others.

No hardware differences between the two boards. On a board in bad condition. Initially, the golden file was used without programming.

I know that is not normal, but I am currently programming the same golden file for all boards. Is there a solution to this problem?

7485.log.xlsx                                                                                                                

  • Hello,

    Can you share your .gg file with the gauge configurations so we can review them?

    If you are using the .gg file for programming and program the wrong firmware version, it may brick the device. For example if you have a BQ27520-G3 and program and BQ27520-G4 unto the older firmware there will be damage.

    Ensure you are using a SREC or BQ.FS file for production programming.

    Sincerely,

    Wyatt Keller

  • Hello, I'm sharing a gg.file with you. Best regards.

    VENO3_FS3_V0.gg.csv

  • Hello,

    Can you explain what you mean that initial testing was performed without programming the golden image? As I mentioned, if you program a .gg file that was exported from a different firmware version or build, it could cause data corruption. That is why the golden image should be a SREC or BQ.FS file, unless the firmware build and version are checked before uploading.

    Also make sure the gauge is powered and not in shutdown, otherwise it will not respond to the EV2400.

    If you are using a custom board please share the schematic and layout.

    Sincerely,

    Wyatt Keller

  • Can you explain what you mean that initial testing was performed without programming the golden image?                                                   

     ⇒I was new to this device and unfamiliar with it.The board was for software development of the system, so I gave it to them without programing golden file.    

    As I mentioned, if you program a .gg file that was exported from a different firmware version or build, it could cause data corruption.                 

    ⇒Is there a way to repair corrupted data or initialize everything? ]

    That is why the golden image should be a SREC or BQ.FS file, unless the firmware build and version are checked before uploading.               

    ⇒Please let me know how to check.                                                                                                                                                                             

    Also make sure the gauge is powered and not in shutdown, otherwise it will not respond to the EV2400.                                                           

    ⇒I checked and there is no problem.                                                                                                                                                                                       

    If you are using a custom board please share the schematic and layout.                                                                                                             

    ⇒I understand . 

    AW,SHEMATIC.xlsx        

  • Hello,

    Is there a process that always yields successful communication and a process that always yields bad communication with the gauge? It looks like it is dependent on the programming method when the issue will occur.

    If your device is corrupted, you can attempt to re-program and enter ROM mode, if the gauge can enter ROM then it can be recovered.

    You can use the FW Version command to check the version number.

    I don't see anything related to the I2C that would cause a problem, is this being used for a 2S design?

    Sincerely,

    Wyatt Keller

  • Hello,

    The error is board dependent. The test condition is constant current discharge, disconnected from other circuits.                                                                           If left in this state, random errors will occur.   

    I have checked the firmware version and it is fine.And I downloaded the srec.file from the TI homepage and programmed it, but that did not improve the problem.

    Can you tell me exactly how to reprogram from rom mode? Can it be done from bqstudio?

  • Hello,

    If you are able to program the firmware successfully, that requires a few seconds of good communication, you don't see any issues during programming?

    After programming a new SREC if the issue is still present then it is most likely something with your hardware or system.

    Make sure you turn the auto re-fresh off during logging because it can interfere with the communication during the logging. Also make sure there are no other devices on the communication bus, the EV2400 does not have arbitration and will give an error if another primary device is communicating.

    Sincerely,

    Wyatt Keller

  • Hello,

    No problems were encountered during programming.During communication with the EV2400, connections to other devices are disconnected.

    Is it possible to ask for an analysis in case of hardware failure?

    Best regards.

  • Hello,

    It looks to me that either the gauge was not programmed correctly and the firmware is corrupt, the gauge is entering in and out of shutdown or doing multiple resets (why the communication has issues and gauging data reported is 0 before initialization)

    If it's only occurring on one board there is a high chance this gauge was damaged or corrupted at some point and it is not related to hardware in production.

    Sincerely,

    Wyatt Keller

  • Hello

    I have asked this question before, but how do I reprogram from ROM mode? I want to initialize everything if the data is corrupted.

    Best regards.

  • Hello,

    You can follow the guide in SLUA801 for how to program a flash stream with your own MCU, or you can use bqStudio. When you write the firmware with an SREC or flash stream bqStudio automatically send the device into ROM mode.

    https://www.ti.com/lit/pdf/slua801

    If the device is already corrupted it may not be able to enter ROM mode and the device would be bricked.

    Sincerely,

    Wyatt Keller

  • Hello.

    I found a difference between my schematic and the schematic in the datasheet.They are the VCC decoupling capacitor(C72) and the input capacitor on the BI/TOUT pins(C73). In this state, the voltage of VCC is falling when the voltage on the BI/TOUT pin rises.(See Figure 1 in the attached file.) This voltage has dropped to the Power-on reset threshold voltage, so it seems to reset.I set the values of these capacitors the same as in the datasheet and the problem was solved.However, there is still a voltage drop across VCC, and the value of C73 must be reduced to about 0.01uF to resolve this.Is there any problem with reducing the value of C73? Best regards.

    VCC VOLTAGE DROP.xlsx

  • Hello,

    Yes if the VCC pin does not have enough capacitance that is placed close to the gauge, it may cause issues during programming since there is a momentary burst of current during flash writes.

    With C72 = 1uF and C73 = 33nF the issue should be resolved. If needed you can increase the capacitance on VCC.

    Sincerely,

    Wyatt Keller