• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 63 subscribers
  • Views 879 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: When reading data from BQ34Z100 do I need a Stop after each block, or will just a restart work?

Kipton Moravec
Expert 1545 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQ34Z100, BQSTUDIO, MSP430F5329

I need to read 4 blocks of data from the BQ34Z100 

I have 4 blocks of data to read.
1, Standard Block from 0x00 through 0x13 or 20 bytes
2, Block 1 from 0x18 through 0x1F or 8 bytes
3, Block 2 from 0x24 through 0x3D or 20 bytes
4, Block 5 from 0x62 through 0x6F or 14 bytes

Normally for a single transaction I would do 

<Start><Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Stop>

And I could do that 4 times, once for each block.

<Start><Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Stop>
<Start><Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Stop>
<Start><Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Stop>
<Start><Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Stop>

Looking at the I2C driver I am using, if I load all 4 commands into one transaction, it would use a <Restart> instead of a <Stop> and <Start> between the 4 transactions. 

<Start><Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Restart>
<Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Restart>
<Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Restart>
<Device Address+W><Command><Restart><Device Address+R><Read data 0>...<Read Data N><Nak><Stop>


Would this work? Or do I need to figure out how to force the <Start> and <Stop> for each transaction?

Thanks, 

Kip

  • 0
    TI__Mastermind 25955 points
    Hi Kip,

    This depends on the implementation restart in the driver.

    The driver may implement restart (but not always!) as a stop condition followed by a start condition (fast enough that another device isn't able to assert on the bus). If this is the case, it may work as long as there is enough time between the commands. Try for at least a 60-120 us delay at first.

    If commands are sent too fast, it may cause a watchdog reset.

    If you are trying to read several parameters at once, it may be more beneficial to perform a large bulk read and then parse the data using the offsets given in the datasheet and bqStudio.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1545 points

    I am still reading the source code of the driver to see how it works. 

    But it is interrupt driven, so I can build a queue of commands and it will execute them. 

    It looks like if the queue is not empty, it does a restart rather than a stop and start. 

    If the queue is empty, then it does a Stop. 

    I searched the documentation "bq34z100 Wide Range Fuel Guage with Impedance Track Technology" SLUSBZ58 for Watchdog, and found it listed in 7.2 Functional Block Diagram but no mention of it in any other place. 

    It says in 6.14 that tbuf the time between Stop and Start is 66 us. Is that what it takes to restart the Watchdog timer? What causes the Watchdog timer to time out? 

    As I mentioned before I am reading 4 blocks, of 20, 8, 20 and 14 bytes of data. (and I have to read them 3 times a second).  I cannot read more than that because they are not consecutive blocks, and I do not know what the bq34z100 does when I try to read undefined memory locations between the blocks, so I did not try. 

    Is the watchdog timer based on time or data? The 4 blocks should take about 6.66 ms at 100 kHz.  Or about 1.66 ms at 400 kHz.  So you are telling me those times will cause the Watchdog Timer to expire and reset the bq34z100?  That does not make sense to me. It seems too fast. 


  • 0 in reply to Bryan Kahler
    Expert 1545 points
    What are the parameters of the Watchdog?
  • 0 in reply to Kipton Moravec
    Expert 1545 points

    I guess this post has fallen off the radar. 

  • 0 in reply to Kipton Moravec
    TI__Mastermind 25955 points
    Hi Kipton,

    The watchdog reset timer is a concern if too many commands are sent during a short period of time, preventing the device from servicing the watchdog reset timer.

    Are you experiencing resets or having difficulty with reading the blocks of data? If the issue still persists, please let me know.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1545 points
    No right now I am having problems with my driver.

    You were the one that said I had to watch out for the long blocks of data reads. I told you what I was reading and why in the first post. And I cannot see any specs for the watchdog timer in the documentation to know if I will be getting close.

    What is too many commands in a short period of time? I need numbers or values or specifications!

    Is the watchdog timer information TI Company Confidential which is why you do not document it or tell me what it is?

    I do not want to run into trouble. And I do want to make sure I am in specifications. I do not want to find out when we build 100,000 of these that some have a problem with resetting, because we were too close to the timeout on the watchdog timer.
  • 0 in reply to Kipton Moravec
    TI__Mastermind 25955 points
    Hi Kipton,

    For the timing information required to be successful with I2C programming, please refer to the device datasheet or this video: training.ti.com/.../gauge-programming-fundamentals at 39:55.

    66 us minimum between every stop and start condition
    Incremental writes (without stop/start condition in between bytes) are only allowed if SCL <= 100 kHz
    No more than two standard commands per second. This is a very conservative rule and can be broken when using a flash stream file (which includes the required delays).

    This FlashStream file is the BQFS and/or DFFS file exported from bqStudio.


    Watchdog timers are commonly used to ensure the device is not stuck in a loop or servicing a request or series of requests for too long. Communication has priority, and sending too many commands too frequently can prevent other device functions.

    The watchdog timer is something to be aware about, but is currently a red herring in this discussion.

    If you believe you are triggering watchdog resets, please used the RESET_DATA command in bqStudio prior to your test and then after your test to determine the number of resets that occurred during your test.


    Please write and test your code, if you're having issues, please let us know.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1545 points

    Thanks. 

    The issue is not writes. The issue is the 4 block reads I talked about in the first page, and if I am expecting problems with them. 

    The reason I am so concerned was that our team has had problems with the bq34z100 "hanging" and not responding when using the MSP430F5329 when using the built-in I2C HW. Their solution, before I arrived on the project, was to manually bit-bang the I2C interface, and the issue went away. Now I am rewriting the code for a different processor and intend to use the built-in I2C interface in interrupt mode. I am trying to prevent my code from having the same problem by understanding what could cause it to hang. (Nobody knows why.) If it had a watchdog reset it would not respond to I2C in the middle of a I2C communications, and the communications would hang. Unfortunately this was a very random occurrence.  It would happen once a day on a system reading data 3 times a second. 

    I know what a watchdog timer is, and it has two things of interest. The Watchdog Timer Reset Time, where the device will reset after a period of time and a timer reset which starts the timer counting from the beginning again.  What I hear, is that during communications the processor in the bq34z100 gets busy and cannot reset the watchdog timer.  And having 66 us between the stop and start is enough time for the timer to be reset. What I do not know is how long I can communicate (reading) before the watchdog times out. I would have thought the 6.66 ms I estimated earlier would be way shorter than the Watchdog Timer. 

    If that is not the case I have to come up with a way to put a 66 us delay between the 3 stop and start pairs when I am in an interrupt.  I do not like delays in interrupts. It is bad coding. If that is the hoop I have to jump through, then that is what I will do. I will figure out something. 


  • 0 in reply to Kipton Moravec
    TI__Mastermind 25955 points
    Hi Kipton,

    Please test this implementation - the 6.66 ms time is much smaller than the watchdog reset timer. 66 us is just the minimum requirement between stop and start.

    The watchdog reset is just something to be aware of - I don't expect it to cause issues for you with the proper delays and number of commands sent per second in place.

    Block reads can be the most efficient way to read large amounts of data from the device. If issues persist once the code is written, please let me know!

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Expert 1545 points

    All of a sudden my I2C started working. The part that bothers me is I do not know why it was not working and why it now is. But that is another issue. 

    So I was able to get the driver to issue a Stop at the end of a command. Unfortunately as it was all interrupt driven, there was only 11.5 us between the stop and the new start. 

    As much as I hate to do it, I have temporally put a wait in an interrupt, so now the delay between the stop and start is exactly 67 us, (1 us more than the minimum for good measure.) 

    Reading all the data I need every 333 ms, is now taking 14.66 ms at 100 kHz., with 4 block reads and 67 us between stops and starts. 

    My next effort is to see if this processor has an extra timer I can use for the 67 us delay, and how that will work. 

    Thanks for your help.