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.

BQ27Z746-DEVICE-FW: Using FlashStream file to program device FW and Flash Data

Part Number: BQ27Z746-DEVICE-FW
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.

  • Just wanted to add that we've now also tried listening in on the I2C comms sent by bqStudio when programming the BQ27Z746 EVM, and noted some major differences between that trace and the protocol outlined within the FlashStream. Namely, the ROM-mode command used by bqStudio is different (it sends 0x0033 to register address 0x00 as opposed to the FlashStream sending 0x0F00 to register 0x00) and it only waits about 30ms before sending commands to address 0x16 rather than the full second specified in the FlashStream. We've tried modifying our FlashStream file to emulate this sequence used by bqStudio, but the result was still the same as before, NAKs on the ROM-mode address of 0x16 as well as the default address afterwards.

    We've also checked to ensure this isn't some kind of hardware failure by trying the same tests on a separate prototype. We still got the same behaviour there as well.

  • Have you tried power cycling the gauge?

  • Yessir, we've been power cycling the gauge before each test run.

    This has actually been a necessity to repeat our tests. Any time we run a test and end up with the gauge in the unresponsive state described above, the only way we can get it to respond again so we can start another test is by power cycling it. The problem isn't that we've gotten the gauge into a state that we can't get out of, it's just that every single time we run the FlashStream parser, the gauge stops responding over I2C at the same point in the sequence. Namely, immediately following the "enter ROM-mode" command.

  • Both commands 0x0F00 and 0x0033 accomplish the same: Getting the gauge into ROM mode. They will only execute, if the gauge was unsealed.

    You can verify this with bqStudio and Advanced Comm:

    This example (which I tried on the EVM a minute ago) shows command 0x0F00 (big endian) on device address 0xAA. The next read from 0xAA NAKs (because the gauge switches to ROM mode). I added this to show that it stops responding on 0xAA.

    The next read from 0x16 returns data because the gauge now is in ROM mode.

  • Thanks for the confirmation on how it works! Good to know both commands are valid.

    The behavior you describe here lines up with what we expect to happen as well. Our problem is that the gauge is NACKing on BOTH addresses (0x16 and 0xAA) and continues to do so until power cycled. I've confirmed that we are correctly unsealing the gauge before attempting to enter ROM mode by reading the OperationStatus A and B registers and confirming that the SEC1,SEC0 go from (1,1) to (1,0) after the two unseal keys are sent, and then again to (0,1) after the two full-access keys are sent. This check was performed separately from the attempts to run FlashStream file, as an experiment to troubleshoot if our issues are caused by a failure to unseal. It doesn't appear that they are.

    The first screenshot I posted is actually of the trace of the successful write of the first unseal key at the start of the sequence. And the two screenshots in the second-to-last line are of attempts to communicate with gauge on address 0x16 after it's been unsealed and commanded into ROM mode. One is very shortly after (30-ish ms) and one is from a different run where we had a longer delay (1 full second). The last screenshot shows that the gauge didn't simply fail to enter ROM mode, since it also stops responding on address 0xAA. 

  • Please run the bqStudio command sequence from my screenshot and check this with your Saleae to see if there's a difference.

    I don't think we can debug this via E2E otherwise. It works fine with the TI tools so there's a reference for comparison. Once the gauge enters ROM mode, it will start responding on 0x16 (0x0B 7-bit). There is no known state where it doesn't respond at all (unless it turned off).

  • Sure thing! I'll have the results posted shortly.

    Out of curiosity, can you think of any reason that the gauge might turn itself off when we attempt to enter ROM mode? The only note we could find was that cell voltage has to be above a set minimum, which defaults to 2100 mV. This is why we use the Voltage() (0x08/0x09) to query the measured cell voltage before starting the sequence and confirm it is higher than that. Are there any other conditions you know of that might affect the device's ability to enter ROM mode?

    Also, is it possible some parameter is being measured out of acceptable bounds and blocking us? For example, we know for a fact we need to change the CC-Gain multiplier (which is part of what we're attempting to flash here). Before changing it, the gauge would very likely be sensing an overcurrent state. Do you know if this could be blocking some functionality?

  • Please check if your sequence somehow triggers auto-shutdown. https://www.ti.com/lit/ug/sluuca6/sluuca6.pdf, 6.6

    This isn't normally related to entering ROM mode.

    The only gating item preventing switch to ROM mode is if the gauge is sealed. Other parameters, like CC Gain, won't affect it. But there are parameters that control shutdown, which could interfere.