• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 816 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.

BQ34Z100-G1: Configuring sleep/full sleep modes

Evan Gates
Prodigy 10 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQSTUDIO

I'm using the bq34z100-G1, communicating via I2C from a microcontroller.
Control() Subcommands for type and version return:

- DEVICE TYPE: 0x0100
- FW_VERSION: 0x0016
- HW_VERSION: 0x0080

I'm having trouble configuring the sleep and full-sleep modes, and
noticed some oddities when dealing with the flash. Data sheet section
"7.3.3.1 Accessing Data Flash" explains how to read and write from the
flash for settings that do not have a Data Command. I've copied the
important paragraph below:

> To access data flash locations individually, the block containing
> the desired data flash location(s) must be transferred to the
> command register locations where they can be read to the host or
> changed directly. This is accomplished by sending the set-up command
> BlockDataControl() (code 0x61) with data 0x00. Up to 32 bytes of
> data can be read directly from the BlockData() command locations
> 0x40…0x5F, externally altered, then re-written to the BlockData()
> command space. Alternatively, specific locations can be read, altered,
> and re-written if their corresponding offsets are used to index into the
> BlockData() command space. Finally, the data residing in the command
> space is transferred to data flash, once the correct checksum for the
> whole block is written to BlockDataChecksum() (command number 0x60).

The example goes through the following steps, which I have followed.
Note I was looking at subclass 68 offset 2 for sleep current instead of
class 64 offset 0 as in the example.

1. Unseal the device. Skipped, my device was not sealed according
to the status register.

2. Write 0x00 to BlockDataControl (0x61) to enable block data
flash control.

3. Write 0x44 (Power Configuration Subclass) to DataFlashClass
(0x3E) to access the registers subclass.

4. Write block offset (0x00) to DataFlashBlock (0x3F)

5. Read 0x42 (Sleep Current). Expected 0x0a for default Sleep
Current of 10mA. Got 0xf0. Then, instead of reading just 0x42,
I read all 32 bytes from 0x40 to 0x5F. Looking at that I see
the expected value.

6. Read the 1-byte checksum from BlocKDataChecksum (0x60). I
found out later that this value was also wrong.

7. Calculate new value. In this case 0x64, the max allowed value
for Sleep Current of 100 mA.

8. Write new value 0x64 to offset 0x42.

9. Calculate and write new checksum to BlockDataChecksum
(0x60). Writing the new checksum based on the one from
BlockDataChecksum I get an I2C NAK. I then calculated the
checksum based on the entire block I read and got a different
number than the one read from BlockDataChecksum. Calculating the
checksum based on the entire block with my change seems to work.
I write that checksum and don't get the I2C NAK, then read back
the entire block and see my changes.

10. Reset the gauge by writing the RESET (0x0041) subcommand to
the Control (0x00) register.

11. Seal the gauge. Skipped, my devices was not sealed to
begin with.

By reading/writing full blocks and calculating the checksum based on
the full blocks I was able to make some changes.

Then when I booted, the device did go into sleep mode according to
the status register. At an early stage during my debuging I think
I remember it leaving sleep mode correctly once more power was drawn.
However, now it cycles between sleep mode and normal mode once a second.
I read the status register via I2C every 100ms and see it change from
sleep mode to normal, then one second later back to sleep, etc.

I also tried to get the device into full sleep mode. I set the FS Wait
and used the SET_FULLSLEEP Control Subcommand. At least once early on it
became completely unresponsive to I2C messages. Now the status register
shows the FULLSLEEP bit always set, even though the datasheet says:

> Status bit that indicates the bq34z100-G1 is in FULL SLEEP mode. True
> when set. The state can only be detected by monitoring the power used by
> the bq34z100-G1 because any communication will automatically clear it.

Questions:

- Any idea why I'm unable to read/write single bytes correctly
after loading a block?

- Is there any way to do a full reset to factory defaults of
all settings? Or does that require a firmware flash?

- Is there a way to flash the firmware from a linux based
computer?

- How can I be reading the FULLSLEEP bit set when the datasheet
says that should be impossible?

- Is there a list of hardware or firmware errata per version?
I'm not saying there is necessarily something wrong with the
hardware or firmware, but the behavior I'm seeing is weird enough
that I'd like to know if there are any problems I need to watch
out for.

- Can anyone give a full example of configuration steps that
have successfully put a device into sleep and full sleep modes?

I'm happy to provide clarification and try any suggestions.

Thanks,
Evan

  • 0
    TI__Genius 10830 points

    hi Evan,

    I wanted to let you know that your post has been assigned to one of our applications engineers. This week takes place our annual Battery Management Deep Dive event for which all our engineers are all hands on deck. He will be able to your post early next week, once this event is over.

    You can check out recordings of much of the material we present at www.ti.com/deepdive

    Thank you for your understanding!

  • 0 in reply to David Hien
    TI__Mastermind 25955 points

    Hi Evan,

    Thank you for the well thought out questions and detailed description of the problem issue.  Let's tackle them one by one below (out of original order):

    (1) Is there any way to do a full reset to factory defaults of all settings? Or does that require a firmware flash?

    To do a full reset to factor defaults requires a flash, but only dataflash needs to be reset by using the DFFS to reprogram dataflash.  If a dataflash reset does not work, a full firmware reset including both instruction and data memory may be performed with an SREC or BQFS import.

    (2) Is there a way to flash the firmware from a linux based computer?

    The golden image will need to be created with a windows computer using bqStudio, however, may be exported from the gauge as a DFFS or BQFS file.  After the golden image is created, then a linux based computer may be used to program the devices in production.

    To flash the firmware + data memory (BQFS) or just the data memory (DFFS) with a linux based computer, please use the ANSI-C code example and steps found in this app note:  http://www.ti.com/lit/pdf/slua801

    (3) How can I be reading the FULLSLEEP bit set when the datasheet says that should be impossible?

    The FULLSLEEP bit should not be able to be read.   - when the device is in FULLSEEP the oscillator is disabled and will take time to boot back up.  We will need to investigate this further.  To allow me to duplicate your findings in the lab, could you please provide:

    1. SREC
    2. Jumper settings utilized for EVM
    3. size of load (if any)
    4. Any other state information for replicating the events

    (4) Any idea why I'm unable to read/write single bytes correctly after loading a block?

    Need to step through the procedure with your SREC in the lab.  Usually is caused be sending a command instead of a subclass, or because the code doesn't handle the auto incrementing of datablock reads.

    (5) Can anyone give a full example of configuration steps that have successfully put a device into sleep and full sleep modes?

    With respect to the checksum, when writing to the device, the checksum must be calculated for the full 32 bytes of data.

    Please increase delay between sending commands. Try with the delay at  > 35 ms for reads, >100 ms for writes, > 250 ms for checksums.

    With the SREC in hand, I'll run through your steps in the lab duplicating the issue.  For guidance on implementation, please refer to this thread.  It's quite long but helpful to step through all the pages (especially 8): https://e2e.ti.com/support/power-management/f/196/t/213060  If it does not prove adaquate, I'll create a walkthrough when stepping through your procedure in the lab utilizing your SREC.

    The thread discusses how commands look returned by the GUI and the ordering seen on the scope (or logic analyzer).  Many times issues are with flipped endian-ness between I2C commands (that implement the SBS style of command) and the data returned.

    (4) Is there a list of hardware or firmware errata per version? I'm not saying there is necessarily something wrong with the hardware or firmware, but the behavior I'm seeing is weird enough that I'd like to know if there are any problems I need to watch out for.

    The TRM has been split out from Datasheet and further revisions to the TRM will be listed therein.

    Sincerely,

    Bryan Kahler

    Find out more about the BQ34Z100-G1 including technical documents and tools/software/firmware and frequently asked questions.  Refer to the quickstart guide to get up and started. Also, learn how to find your chemID and perform voltage and current calibration.