• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 63 subscribers
  • Views 853 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.

RTOS/BQ27621-G1: BQ27621-G1 Reading the Gauge Registers

Dilbert K
Expert 1210 points
Part Number: BQ27621-G1

Tool/software: TI-RTOS

I am having lot of trouble going through the "Gauge Configuration Parameters".

I follow the steps in SLUUAP5A-Quickstart Guide for bq27621-G1 :

  • On Figure2 : 
  • Voltage[2] = I2CReadSubCommand(0x04, 2, 100) 
    • I2CWrite(0x04, 100)
    • Buffer[2] = I2CRead(2, 100)

What does it really mean in I2C command code ??  what is the "100" ?

My understand from SLUUAD4C-Technical Reference

  • Table 4.1 
  • Voltage() and Flags() are all Standard Commands

So, I have been using following sequence to read :

  • rd 0x06 Flags_register[0];
  • rd 0x07 Flags_register[1];

BUT, definitely there are issues.  Because when I follow the instruction in (Figure 1) of SLUUAP5A-Quickstart Guide.

The [CFGUPMODE] bit come back with first try.... The checkcsum returned is incorrect... this imply chip is not ready yet.

If I put a long delay, it is fine.

So, my question is : what had I done wrong in reading the Flags_register ?

Why doc said those registers are "I2CReadSubCommand"

Thanks for advice.

  • 0
    TI__Guru 62386 points

    The "100" is a 100us delay.

    Detailed instructions and code examples are in this app note: www.ti.com/.../slua801.pdf

  • 0 in reply to Dominik Hartl11
    Expert 1210 points

    I did follow all the example and running into issue whenever I write into checksum

    • i2cWrite (0x60, 0xAB);      // e.g. 0xAB is new value
    • I am using TI SimpleLink SDK i2c driver....  It stuck in I2CCC26XX_primeTransfer(handle, transaction);

    Only if I update Checksum value.

    On the side note : why doc said Voltage is SubCommand ??

    Voltage[2] = I2CReadSubCommand(0x04, 2, 100)

  • 0 in reply to Dilbert K
    TI__Guru 62386 points
    Voltage is not a subcommand. It's a standard command.

    I'm not sure about the SimpleLink I2C driver. Maybe someone from the CC26XX group/BT LE E2E can help?
  • 0 in reply to Dominik Hartl11
    Expert 1210 points

    Below is the sequence I follow the doc.  Just for the test, I need to put a long delay before I can write to the same checksum again after Step 6.  

    If I put the delay before Step 4 or remove delay then the write Checksum will lock up (due to device will not response & i2c driver wait forever)

    So, my concern is, what I had done wrong that RAM update not ready for programming ??

    // Step 1 // NOTE : subCmd address=0

    gaugeWriteSubCmd(0x8000); // UNSEAL key1

    gaugeWriteSubCmd(0x8000); // UNSEAL key2

    // Step 2

    gaugeWriteSubCmd(0x0013); // SET_CFGUPDATE

    // Step 3

    for (count=0; count<50; count++) //

    {

    flags = gaugeReadCmd(0x06); // CONFIG UPDATE-bit4

    if ((flags & 0x0010)) // wait till BIT4 set

    {

    break; // exit loop

    }

    else

    DELAY_MS(20); // wait up to 20ms*50=1s

    }

    // Step 4

    gaugeWriteByte(0x61, 0x00); // enable block data memory control

    // Step 5

    gaugeWriteByte(0x3E, 0x52); // access Design Capacity parameter

    // Step 6

    gaugeWriteByte(0x3F, 0x00); // access Data location

    DELAY_MS(1500); // wait for 1.5sec

    old_cs = (uint8_t)gaugeReadByte(0x60); // OLD Checksum

    gaugeWriteByte(0x60, old_cs);     //  OLD checksum

  • 0 in reply to Dilbert K
    TI__Guru 62386 points
    You should not need such long delays.

    The code from SLUA801 was tested with the bq27621 and it didn't require these long delays. While this ran on a Linux platform, the actual I2C transactions were "fast" in the sense that there was no significant delay between packets (besides the delays in the code).

    The recommended delay between writing the check sum and verifying the check sum is 10ms.

    Here is a typical sequence that works (extracted from a bq27621 fs file):
    W: AA 3E 52 01 // subclass 0x52, block 1
    W: AA 40 00 02 02 BC 13 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // block data
    W: AA 60 F3 // write check sum
    X: 10 // wait 10ms
    W: AA 3E 52 01 // subclass 0x52, block 1
    C: AA 60 F3 // read check sum and compare
  • 0 in reply to Dominik Hartl11
    Expert 1210 points
    I do understand this is not a normal case which require such delay and lock up. Can you think of any possible cause or I had done wrong in init sequence ??