• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 62 subscribers
  • Views 672 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.

Issue programming BQ27541 with bqfs

Ryan Que
Prodigy 20 points
Other Parts Discussed in Thread: BQ27541

Hello,

Here is my issue.  I generated a bqfs file from a known-good .senc file using the flashStream program.  I have a microcontroller that programs the bqfs lines into the BQ27541 gauges via I2C.  For the past few months, this has been working without any problems.

Recently, there has been a different batch of BQ27541 that came with slightly older firmware V1.12 (we have been using gauges pre-programmed with V2.00).  For this batch, I keep getting a response of 0x02 at the first Compare line after the first 96-byte write attempt. 

To troubleshoot, I tried using an EV2300 with the EVSW to program the senc file.  At first, the software did not recognize that it was in ROM mode (even though it would respond to writes to address 0x16).  I was told to update the EVSW software and I was successfully able to program the senc file after that.  (The fact that my original version of EVSW could not program it tells me that it is a different batch of BQ27541 ICs, but I am unsure if it is related to the 0x02 response when programming the bqfs file).  I used the EV2300 to flash a V2.00 image onto the gauge, then I tried using my bqfs programmer on it again.  The result was the same.

My question is, what has changed recently in the BQ27541 architecture?  I've been told that a stricter I2C protocol was forced on gauges post-2011, but a response of 0x02 means a checksum error, not an I2C error.  Is that correct?

Thanks

  • 0
    Prodigy 20 points

    I've figured it out.  A new batch of BQ27541 require the I2C communication to follow the specifications much closer than they used to require.  In my case, the routine I used to read and compare the checksum did not include a I2C stop command (code bug).  Because of this, the next Write command after the Compare was unsuccessful and the fuel gauge did not acknowledge some of the writes, thus throwing off the whole programming routine.