bq27421 Watchdog Reset

Hi,

I am still having this issue. Any ideas why I am getting a WDRESET after updating these parameters?

Thanks!

I think it may have to do with your command timings. For your I²C commands, are you waiting long enough for the commands to complete before sending additional data to the gauge, and I presume that you are using your own host microcontroller to read the gauge as opposed to the EV2300/EV2400 and GaugeStudio?

On the bq27421-G1A datasheet, page 13:

"For read-write standard command, a minimum of 2 seconds is required to get the result updated. For read-only standard commands, there is no waiting time required, but the host must not issue any standard command more than two times per second. Otherwise, the gauge could result in a reset issue due to the expiration of the watchdog timer."

Jason is quite probably correct.  Out gauges can actually handle upwards of 10,000 I2C transactions per second, but if you hammer it continuously over I2C then the IC will not have time to reset the watchdog timer and it will reset.  Since the gauge registers are only updated once per second, there is no need to read them more frequently.  Please ensure your processor is not communicating too frequently to the gauge.  I recommend you put an I2C snooper on the bus and analyze the traffic.  You could also try to debug by slowing down your communication sequence and sending only one command per second, or something similar.  Please let us know if this fixes your problem.

I am interested in this same type of issue.  I have not experienced this happening, but I am concerned about it because of the note on page 14 of the bq27421-G1 datasheet (SLUSB85C).  Is this note regarding writing or reading Standard Commands or both?  In the TRM and the Quickstart Guide, there are flowcharts with loops to check certain bits in the Flags register (i.e. CFGUPMODE).  In order to do this, I need to poll the gauge and read the register until I see that the bit is set (or cleared).  Is this something that needs to abide by the 2 Standard Commands per second specification?  My I2C clock is only running at 100kHz.  My intent is to perform the following for configuration (all abiding by the 66us command waiting time between I2C commands):

1. Check if ITPOR is set or cleared
2. If ITPOR is set, send 0x00, 0x013, 0x00 (SET_CFGUPDATE)
3. Read the Flags register
4. If CFGUPMODE==0, repeat step 3
5. If CFGUPMODE==1, send 0x61, 0x00 (BlockDataControl)
6. Set Design Capacity
7. Set Design Energy
8. Set Terminate Voltage
9. Set Load Mode
10. Set Load Select
11. Set BATLOWEN bit
12. Set SOC1 clear threshold
13. Send 0x00, 0x42, 0x00 (SOFT_RESET)
14. Read the Flags register
15. If CFGUPMODE==1, repeat step 3
16. If CFGUPMODE==0, done

This requires reading the Flags register, writing the Control register then repeatedly reading the Flags register all within a short period.  Is this acceptable?  This doesn't seem like it's doing a whole lot -- especially since you state that it can handle upwards of 10,000 I2C transactions per second.  What is the 2 Standard Command per second specification for if it can handle 10,000 I2C transactions per second.

Alternatively, is there a way to use the Extended Data Commands to read the data from the Standard Command registers?

Thanks,

Jim

Hi Jim,

The note on page 14 is regarding both reading and writing standard commands as well as control subcommands.

The set_CFGUpdate is a control subcommand and the diagram shows that the timing between issuing and reading for control subcommands to be 66us.

The host must not issue one standard command more than twice per second.

thanks

Onyx

Hi Onyx,

Can you check with the factory on the actual limitations for the I2C commands?

Also, stating that sometimes a higher timing is required is not an acceptable answer as the minimum required time specified by the datasheet is 66us.  That means that anything less than 66us is out of spec, but 66us is within spec.  Is there an issue with the specified values in the datasheet?  The value is the same for both 100kHz and 400kHz.  Is that a mistake?

Jim

Hi Jim,

I do not believe that is a mistake. The wait time is a minimum of  66us in both cases as shown in the I2C compatible interface communication timing characteristics table on page 8 of the bq27421 data sheet. As you can see in the table the minimum time is 66uS, there is no normal or max time. On a sample code we have written, we used 200uS because we saw 66uS didn't work all the time for us either.

I have reached out to our firmware engineers on the actual limitaion of the I2C commands. Once I get a response, you will be updated.

thanks

Onyx

Hi Onyx,

Did you get any reply on the timing issue. I'm also facing the same issue. Fuel gas gauge WDRESET always set and whatever value I'm updating in the data block is getting reset every time.

Regards,
Manoj