Other Parts Discussed in Thread: EV2400, BQSTUDIO, BQ27Z746
Hello,
We're trying to use this fuel gauge component in our product and part of our production sequence requires that we overwrite the device's flash data with the correct chemistry and calibration data. We've been able to generate a "golden image" FlashStream file for our parameters using bqStudio in conjunction with the EV2400 communicator and an EVM. However, we're having some trouble executing the communications specified in this FlashStream file through our MCU. Specifically, we've narrowed down our main issue to the fact that, after the initial instructions send the unseal and unseal-full-access keys followed by a command to enter ROM mode, the fuel gauge no longer responds (ACKs) any further messages, be they addressed to the ROM-mode address specified in the TRM (0x16) or to the original address on which it was responding previous to the ROM-mode command (0xAA). All of the initial messages have been confirmed to be transmitted and acknowledged correctly by tracking the i2c buss in question with a logic analyzer. We've confirmed that the unseal keys being sent are correct and that the gauge reports the expected changes in its security mode after each step in the sealed->unsealed->full_access sequence. We've also confirmed that the gauge is reporting roughly 3.3 V as the cell voltage, which is well above the default minimum required to access flash, according to the TRM. We've also added provisions to ensure the device is in SEALED mode before we attempt to unseal it, as we noted according to some other forum posts that sending the unseal keys when already unsealed could be an issue.
At this point, we feel like we've exhausted our troubleshooting and debugging options and would like some guidance. Any indication of what might be going wrong, or direction as to how we can move past this roadblock is appreciated.
In case it may be relevant, the MCU we're using is an STM32H7, and we're communicating with the fuel gauge exclusively over I2C.
Screenshots of the communications mentioned provided below:
this is what successful comms pre-ROM mode command look like
This is what the ROM-mode command itself looks like
these are examples of attempts to communicate with the device in ROM-mode failing
And this is an example of attempts to communicate with the device using its original default address (after the ROM-mode command) look like.