Firmware seems unstable, help?

[emersonknapp]

This project seems really useful. I am trying to use it to communicate with a smart battery / charger combination

https://www.rrc-ps.com/en/battery-packs/standard-battery-packs/products/rrc2054/
https://www.rrc-ps.com/en/power-management/power-management-modules/products/rrc-pmm240/

When I run watch -n 1 smbusb_sbsreport, it usually works a few times, but then starts failing consistently with all error values, like below

Manufacturer Name:          ERROR                                                                                                                                                                                   
Device Name:                ERROR                                                                                                                                                                                   
Device Chemistry:           ERROR                                                                                                                                                                                   
Serial Number:              4294967289                                                                                                                                                                              
Manufacture Date:           8390587.15.25                                                                                                                                                                           
                                                                                                                                                                                                                    
Battery Mode:               fffffff9                                                                                                                                                                                
At Rate Time To Empty:      4294967289 min                                                                                                                                                                          
At Rate OK:                 4294967289
Temperature:                -273.85 C
Voltage:                    4294967289 mV
Current:                    -9 mA
Average Current:            -7 mA
Max Error:                  4294967289 %
Relative State Of Charge    4294967289 %
Absolute State Of Charge    4294967289 %
Remaining Capacity:         4294967289 mAh(/10mWh)
Full Charge Capacity:       4294967289 mAh(/10mWh)
Run Time To Empty:          4294967289 min
Average Time To Empty:      4294967287 min
Average Time To Full:       4294967289 min
Charging Current:           4294967289 mA
Charging Voltage:           4294967289 mV
Battery Status:             0xfffffff9
Cycle Count:                4294967289

When I power cycle the FX2LP, then I start getting real values again. I unfortunately don't understand the code well enough to understand why this might be happening. Any ideas?

[karosium]

Hi,

I probably won't be able to help since I've never had this issue with the packs I've worked on but if you're getting that output it means the firmware is still running and responding to commands so this seems like some kind of communications issue to me at first glance.

Does disconnecting and reconnecting the SMBus wires (without resetting the controller) have any effect when the interface is in this state?

Does anything change if you modify SMBEnablePEC(1); to SMBEnablePEC(0); in smbusb_sbsreport.c?

[0r10nV]

@emersonknapp
Some Gas Gauging ICs really could stuck communicating on SMBUS when quering requests frequently by FX2LP boards.
The reason still not clear but in some cases reconnecting SCL and SDA lines would restore normal communication. If not then power-on reset of the dev board is required.
Have noticed that some battery packs based on bq8055 are subject to this issue.
Do you know which Gas Gauge IC is used in your battery packs?

[emersonknapp]

Yes, I have experienced that reconnecting the SCL and SDA lines fixes the issue. Do you have any idea how I could make this happen in software?

Unfortunately I don't know what gas gauge they're using inside the RRC2054 battery, I'm hesitant to crack it open since it was a little pricey.

I'm currently solving my problem by using a CP2112 which seems to have more stable communication (sometimes get read errors but then it comes back, I think it may be my calling side not waiting for a transaction to complete) - I can close this issue for now since I don't think I'll be actively following up on it.

[0r10nV]

Good to know you found a solution!

By the way similar issues could happen when communicating in MultiMaster environment due to lack of arbitrage on the bus. You have noted that you are working with Pack/Charger combination so collisions could occur with another bus Master while simultaneously talking with one slave.

Me beleive that it's not easy to solve such issues at high level software side. It needs to look at Cypress documentation for EZ-USB i2c hardware engine and then to modify FX2LP firmware. At first glance it's need to emulate "Smbus disconnect" event by changing SCL and SDA to z-state.

Regarding Gas Gauge used in your specific battery pack it's not compulsory to crack it)
With high probability chip could be detected by smbus scanning for i2c register's signatures (aka "gauge fingerprints") using discovery tools developed by Victor and available in this project.

[emersonknapp]

That sounds useful, what "gauge fingerprints" should I look for? Is there a list somewhere that I could consult?

[0r10nV]

There is no collected lists in one place. Usually they distributed in users working directories if they care about saving those "fingerprints" for future references.
Some ICs has autodetect features built-in by chip manufacturers.
You could run "smbusb_scan.exe -w 16" and send me the output for checking with my lists.
It's better to continue in PM not to off-topic here.
orionv76(at)"Google Mail Dot Com"