Read BQ27510-G2 dataflash in ROM mode

Hi Alexandre,

What is your goal?  TI intentionally does not release the ROM command information for these gauges.  Maybe we can find another way to meet your purpose.

dMax

I am having problems with bq Evaluation Software and Windows 7 x64 drivers for EV2300. So I thought that an approach would be not use the "average method" described on documentation and just select one of my more than used boards to be the "golden image". To do this, I needed to extract the dataflash content and write it on the new boards.

Question: is it possible to do it without entering ROM mode? I mean, unseal the "golden" chip, copy the dataflash of every documented subclass (Table 7. Data Flash Summary) and write this content as binary on the new boards. I am afraid that the non-documented subclasses (some of them have values different from zero, I checked) are important too.

Hi Alexandre,

Unfortunately your method will not work.  The undocumented subclasses include lots of important information that is static and/or proprietary and must also be written to the flash for successful operation.  You do need to enter ROM mode for production with bq27510.

No problem, with a lot of effort I was able to decode the "protocol" used by bq evaluation software. We must use the command 0x07, with 4 bytes of addressing, starting at 0x20004000.

This way:

Write 0700400020 to addresses 0x00~0x04, then write 6700 to addresses 0x64~0x65 (checksum), then read the first block of DataFlash from addresses 0x05 ~ 0x24

Write 0720400020 to addresses 0x00~0x04, then write 8700 to addresses 0x64,~0x65, read the second block of DataFlash from addresses 0x05 ~ 0x24

...

Write 07E0430020 to addresses 0x00~0x04, then write 4a01 to addresses 0x64~0x65, read the last block of DataFlash from addresses 0x05 ~ 0x24

Yes, it wasn't obvious...

Thank you, I've been trying to write code to check that the correct golden file has been loaded on bq27410-g1 fuel gauges.  Being able to read back the entire golden file rather than just the pieces accessible through the sub-classes is very useful.

Curiously for me row 0, byte 24 keeps changing value and rows 28 and 29 sometimes change to the same as rows 0 and 1.  I thought that the golden file was held in ROM.  Are these supposed to change or is there something wrong with my code?  The rest of the golden file appears to be pretty stable.

You are reading the "data" part, so it's normal that it changes. The golden file is composed by a "firmware" part and a "data" part.

How can I tell which bits of the golden file are data and which bits are ROM?

My test is usually very successful but I would prefer to test only the ROM parts.

As it now stands, I check rows 0..27 but skip bytes 23 and 24 of row 0.

//*****************************************************************************
// @brief Reads the flash and compares it to what will be written.
// @details This routine goes into ROM mode and issues command 0x07 to register
//          0x00 followed by the address 20004000 with 32*row number added.
//          thus the 5 bytes 07 00 40 00 20 are issued to registers 0x00..0x04
//          for the first row and 07 20 40 00 20 are issued for the second row
//          and so on until 07 E0 43 00 20 are issued for the last row.  The
//          checksum much be issued to registers 0x64 and 0x65 and this is
//          calculated by summing the bytes issued to registers 0x00..0x04.
//          Finally the 32 byte data row can be read from registers 0x05..0x24.
// @return Number of matching bytes (should be at least 896)
//*****************************************************************************
uint16 BATT_flash_match(void)
{
 uint16 i = 0;
 uint32 irow = 0;
 uint32 chksum = 0;
 uint32 writedata = 0x000000UL;
 uint16 result = BATT_OK;
 uint16 match = 0;
 uint8 BATT_ROW_DATA[32];

 for (irow = 0; result==BATT_OK && irow < 28; irow++)
 {
  for (i=0; i<32; i++) BATT_ROW_DATA[i] = 0;
  // Write 0700400020 to addresses 0x00..0x04
  // but add irow*32 to second word
  writedata = 0x0700UL;
  chksum = 0x07;
  BATT_wr(BATT_I2C_ROM_MODE_ADDRESS,(uint8 *) &writedata,2,0,0);
  writedata = 0x400001UL + (irow<<13);
  chksum += ((irow<<5) & 0xFF);
  chksum += (0x40 + (irow>>3));
  BATT_wr(BATT_I2C_ROM_MODE_ADDRESS,(uint8 *) &writedata,3,0,0);
  writedata = 0x200003UL;
  chksum += 0x20;
  chksum += 0x00;
  BATT_wr(BATT_I2C_ROM_MODE_ADDRESS,(uint8 *) &writedata,3,0,0);
  // Compute checksum and issue to registers 0x64 and 0x65
  writedata = 0x000064UL + (chksum<<8);
  BATT_wr(BATT_I2C_ROM_MODE_ADDRESS,(uint8 *) &writedata,3,0,0);
  writedata = 0x05UL;
  BATT_wr(BATT_I2C_ROM_MODE_ADDRESS,(uint8 *) &writedata,1,BATT_ROW_DATA,32);
  for (i=0; result==BATT_OK && i<32; i++)
  {
   // Check that there is a match, but bytes 23 and 24 are CC offset and occasionally change
   if (BATT_ROW_DATA[i]==golden[match] || match==23 || match==24) match++;
   else result = BATT_GOLDEN_IMAGE_MISMATCH;
  }
  MSP_waitms(20);
 }
 return match;
}

Note: the function BATT_wr(I2C_ADDRESS, WRITE_BUFFER_ADDRESS, NUMBER_OF_BYTES_TO_WRITE, READ_BUFFER_ADDRESS, NUMBER_OF_BYTES_TO_READ) is used to communicate with the battery gauge using I2C.

Addresses 63, 64, 74 and 542 also appear to change.  Variable locations seem to be thoroughly mixed in with the constant ones.

Thank you for your reply.

We're using the bqEASY program to initially determine the .dfi file for the device.

Now bqEASY only has a file called bq27410_1_01.dfi, which I am guessing is the G1 firmware.

How can I get hold of the G3 firmware for the bq27410?

Best regards,

Thomas

Thank you very much.  Sorry, it's my fault for going off topic slightly ... my battery gauge is the bq27410-g1 which is very similar to the bq27510 but I'm not sure I would risk using the same .dfi file on it.  I only posted here because the issues I was facing were very similar.

Regards,

Thomas