Other Parts Discussed in Thread: BQSTUDIO
Tool/software:
We have a new design that is using a bq27427 Battery Gauge.
The gm.fs file produced by Battery Management Studio (V1.3.124, i.e., the latest version) contains code like this to initialize each of the Data Blocks of the Battery Gauge:
But executed literally by our Battery Gauge Initializer subroutine (that just interprets and executes our pre-processed version of that gm.fs file), this doesn't work. It fails the very first time it tries to verify the checksum of a programmed data block.
And when I look at the BQ27427 Technical Reference Manual (SLUUCD5, JANUARY 2023) I instead see this advice for when to introduced delays into the programming steps:
That is, have many more delays than just that one 10 ms delay that Battery Management Studio called for.
And this appears to be good advice: when I add a blind delay after every step of the programming recipe (such that I never advance to the next step without at least 2.5 ms of delay), initializing the Battery Gauge succeeds.
So this leads me to some questions:
- Is the gm.fs file being produced by Battery Management Studio just plain wrong about the necessary delays?
- If so, does TI acknowledge this bug and have plans (e.g., a filed bug report) to correct it?
- And in the meantime, I should follow the advice in the Technical Reference Manual, right?
- But how short can those delays be? I'm getting away with having them set to 2.5 ms (except for, for example, Step 10 where I'm getting my general 2.5 ms delay PLUS the 10 ms delay explicitly asked for by the gm.fs file). Battery Gauge Initialization happens at every start-up of our device so we hate to have this process take longer than the absolute minimum time required.
- Is that minimum delay specified in the Data Sheet? (I haven't found it.)
