• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 31 subscribers
  • Views 1293 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C123AE6PM: How well does this microcontroller handle the multi-master case?

Louie
Expert 3180 points
Part Number: TM4C123AE6PM
Other Parts Discussed in Thread: BQ40Z50

Hello,

I currently have a customer with this issue:

"

We are shipping systems with the TI microcontroller TM4C123AE6PMI7R. In one of the uses, one of its I2C buses is connected to a TI smart battery (bq40z50) and TI smart battery charger (BQ24725ARGRT). We occasionally get corrupted battery data reported, specifically the current. We are not sure whether this happens during a discharging cycle or charging cycle. We communicate to the micro-controller through a CAN interface.

"

How well does this micro-controller handle the multi-master case?

Thank you,

Louie

  • 0
    TI__Guru 72500 points
    In general, very well. However, there is an issue with the glitch filter which is described in the errata document:
    www.ti.com/.../spmz849f.pdf
    I doubt that the glitch filter is the issue, but it could be related.
  • 0
    Guru 117855 points

    Louie said:
    We occasionally get corrupted battery data reported, specifically the current.   We are not sure whether  this happens during a discharging cycle or charging cycle.

    No mention of:  "How & When" such "Corrupted Data" is reported!        Such may prove insightful - might it not?

    It would appear - that  "such Data Reporting"  has a  "high likelihood of KNOWING" - whether,  "Charge or Discharge" is "underway."     

    Would not that,  "Battery Data Report" be ENHANCED - by including,  "Charge vs. Discharge status?"     (Even if - and especially if -  neither "bq" device - provides such data!    Your '123 should be able to,  "Fill that GAP!")

    Is it just me ... or has (somehow) the "Multi-Master" issue - been (pardon) "Less than well detailed?"

  • 0 in reply to Bob Crosby
    TI__Expert 3180 points

    Hello Bob and cb1_modile,

    Thank you for the response, I will pass this on to my customer.
    I apologize for how vague this is, I am probing for a little more information.
    I just wanted to get the conversation started or if anyone had seen similar problems.

    Thanks,
    Louie

  • 0 in reply to Louie
    Guru 117855 points
    Pardon - but may it be assumed that (some) of the detail supplied in your behalf (beyond Bob's) may also receive such passage? (your response targeted (only) Bob...
  • 0 in reply to cb1_mobile
    TI__Expert 3180 points
    Hello Bob,

    The customer is currently looking at the glitch filter manual.
    Thank you!

    Hello cb1_mobile,
    To address a lot of what you pointed our in your first post:
    "Specifically we are getting occasional operation status reads that indicate that the discharge FET has been turned off while we are performing a learning cycle. There is no apparent reason for this as we discharge to no less than 70%. We do inhibit the charger to allow for a rest period until the rest flag is set but I don’t see why that should cause it to happen."
    I was still waiting for a response before moving forward with a response, apologies on any misunderstanding.

    Thank you,
    Louie
  • 0 in reply to Louie
    Guru 117855 points

    Thank you, Louie - and also for "adding me" to your earlier response.
    Firm/I have substantial Li-Ion Battery Design Implementation/Charger experience - so should be able to offer (some) insights.

    Should the discharge FET be controlled by either "bq" device - I'd suggest that you monitor the FET's gate drive - w/a "free" MCU GPIO - and in that manner you will KNOW - if the issue(s) occurred during the discharge cycle.     (some of our designs employ, "multiple" discharge FETs - which enabled "variable" Discharge Rates/Levels.    (ORing the gate drive signals - allowed us to "know" - that "Discharge" had been "commanded" - and was "underway.")    

    That same technique - switched to "Charge On" - revealed the alternative situation. 

    It is assumed that you/client employ "only" the cells from one of the four "Leaders" - cells from (lesser) sources - prove "Less Costly" - and that perhaps - for (very) good reason...

  • 0 in reply to cb1_mobile
    TI__Expert 3180 points
    Hello cb1_mobile,

    Unfortunately, my customer is unable to reproduce this on their end and these issues were reported from systems sent out to the field. The issue that they are concerned about isn't whether it is discharging or not. It’s not that we are not reading any data from the battery pack, it’s that the operation status reports a discharge FET inactive. Or at least the operation status read by the microcontroller and passed along through CAN to our service processor which makes the determination of the discharge FET is off.
    Unfortunately, at this point, I will look to you and your teams guidance on the issue. I think he is more concerned as to why this is happening and still narrowing down if this device could be culprit. However, without a way to consistently reproduce the problem, i am hesitant about the what our next steps would be.

    Louie
  • 0 in reply to Louie
    Guru 117855 points

    You should know that my small tech firm is "not" part of T.I. We are interested - and try to be helpful - and enjoy reasonable growth & success - as "outsiders."

    Under the conditions you describe - when the issue (may) or may not - be CAN Bus related - the use of "redundant" signalling (even if temporary) often "Speeds, Eases & Enhances" source issue discovery & correction... (i.e. It is assumed that an MCU performs key measures - and those are transferred via the CAN Bus. Should the Bus prove "suspect" - redundant connections - from "Key Monitored Points" - which connect in parallel - between the CAN Master - and "secondary" MCU - are often able to, "Cast a Brighter Light" upon such issues...

    It remains "unclear" as to, "How & Why" the "multi-master" became suspect.

  • 0 in reply to Louie
    TI__Guru 72500 points
    Louie,
    Any update on this issue?
  • 0 in reply to Bob Crosby
    TI__Expert 3180 points

    Hello,

    Fortunately, post the suggestive debug method provided by cb1(Thank you!), there were no further questions.

    If I get an update, I will be sure to respond.

    Thank you for following up!

    Louie

  • 0 in reply to Louie
    Guru 117855 points

    Greetings and thank you.     We have designed & implemented (multiple) size/type Li-Ion Battery Packs - (often using your newer BQ devices) - many for a variety of multiple, Cordless Tool vendors.    (and multiple special/unique Apps  (i.e. lawn mower (56V) and growing)    Prevents (unwanted) Early Sat (or Sun) Mowing Wake-Up.

    The simple 'TM4C123' serves as a very nice, "multi-cell" Li-Ion Battery Monitor" and is able to log battery voltage while enabling powerful Charge/Discharge (especially during Development) Diagnostics.    (works w/multiple of your "BQ" family of devices - yet also w/those of 'Maxim' - should that prove useful...)

    Uniquely - using one of our high-contrast displays - we can (simultaneously) Display the cell voltage - and Charge/Discharge RATE - of up to 20 Li-Ion cells - in multiple 'Series-Parallel' Pack arrangements...    The device can "Sit & Monitor" - while data logging - and alarm based upon multiple "Client-User Concerns!"     (Fault's Source - as well as date/time - and cell voltages - along w/Load - all logged!)