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.

Understanding the bq78350-R1

Other Parts Discussed in Thread: BQ76200, BQ78350-R1, BQ78350, BQSTUDIO

This is the first BMS I’ve designed for a lithium ion battery pack and I’ve spent quite a while studying the datasheets, TRMs, application notes and EVM documentation for the bq769x0, bq78350-R1 and BQ76200.  I eventually figured out most things but I still have some questions regarding a few subjects in the Technical Reference SLUUBD3B. Any help clarifying these things would be very much appreciated

 

Various

  1. Please define REST (RELAX) mode. It’s possible to infer what it means from the context and diagrams in the TRM but an exact definition would be preferable.

TRM Chapter 4 Permanent Fail

  1. Can the bq78350-R1 be taken out of Permanent Fail for post-mortem testing and evaluation purposes?

TRM Chapter 8 Power Modes

  1. I assume AOLD and ASCD are active during the Sleep Mode, please confirm

TRM Section 11 .1 Device Security, Description

  1. What access is not available in UNSEALED that is available in FULL ACCESS?

TRM Section 11.5.3 UNSEALED to FULL ACCESS

  1. What is the “command to go to boot ROM” and what is it used for?

Thank you for your assistance

  • Sheldon,

    1. The relaxed mode would be when the pack is not charging or discharging. The current is below the Quit current.

    2. Yes, you can issue the PF Clear command to access the data flash.

    3. The hardware based fault protections, AOLD and ASCD, cannot be disabled and they are active in all modes.

    4. You cannot load an srec file to the device.

    5. You can use the Write Word option and write 0f00 to 00.


    Tom

  • Thank you Tom, I appreciate your clarifications. I never like to assume anything.

    I'm not clear on why one would want to use the Write Word option and write 0f00 to 00. What reason would one have to go to the boot ROM?

  • You have to go to ROM mode if you need to reload the default srec.
  • Thank you Tom.

    I've been familiarizing myself with the content and format of the gg.csv file and I have some questions about the five "Data Types" listed in the file. The're not defined anywhere but I assume they are:

    F = flags

    B = binary

    U = unsigned INT

    I = signed INT

    S = string

    Are my assumptions correct?

    Three different Data Types, F, B and U, are used to define data flash variables that contain "Flash Bits". What is the significance of using different data types to define the flag variables?

  • Hi Sheldon,

    The data formats should resemble what is defined in the BQ78350 TRM. In the latest TRM, data formats are described in Section 18.2
    And F = float
    You can see how the floating point number is described in that same section.
    So binary will be used to set individual bits that represent an ON/OFF state.
    Unsigned INT allows you to store numbers using all bits including the MSB. U can be 1, 2 or 4 bytes
    Signed INT uses the MSB to define the sign of the number, and it uses the 2's compliment representation.

    Regards,
    Michel
  • Thank you Michel, I missed section 18. I guess it doesn't matter that the flash memory locations that contain bit fields are typed as both B and U.

    There appears to be a contradiction in the bq778350-R1 TRM. We want to use the CHG FET for Pre-Charge.

    In Section 2.6.2 FET Options, it states:

    PCHG_EN: Enables the bq78350-R1 to use the PRECHG pin during PRECHARGE mode.
        0 = The bq78350-R1 never uses PRECHG.
        1 = The bq78350-R1 controls PRECHG under normal charge control algorithm (default).

    This would seem to imply that [PCHG_EN] should be zero if no separate PCHG FET is used.

    But in Section 5.2 Fast and Pre-Charging, It states:

    FET Options[PCHG_EN]

    FET Used

    0

    PCHG

    1

    CHG

    That seems to be contradictory, stating that should [PCHG_EN] = 1 to use the CHG FET.

    I guess I'm confused, we would like to use the CHG FET for Pre-Charge, what value should [PCHG_EN] be??

    I assume this bit only determines which FET is used for Pre-Charge and has no other effect on the PRECHARGE Mode.

    In our design we have not made any connection to PRECHG, pin 5 on the bq78350-R1. Since we intend to implement a Pre-Charge function in the charger, should we disable the PRECHARGE Mode altogether or just configure it as a safety backup to the charger with slightly higher limits?

  • Hi Sheldon,
    This does look like a contradiction indeed. Section 5.2 also says to set the precharge current to 0 to disable the pre-charge function.
    Can somebody from TI confirm or explain what the FET Options really do?
    Michel
  • Setting the PCHG_EN bit = 0 will enable the CHG FET and disable the PRECHG FET when in pre-charge mode.
    Setting the PCHG_EN bit = 1 will enable the PRECHG FET and disable the CHG FET when in pre-charge mode.
  • The bq78350-R1 TRD, Section 16.5 Broadcasts to Smart Charger and Smart Battery Host,  refers to a data flash parameter SMB BCAST Time. I cannot find any mention of SMB BCAST Time anywhere else in the TRD or in bqStudio 1.3.52 and it appears to be undefined. Am I missing something? Does SMB BCAST Time exist and, if not, how is the timing of the AlarmWarning() broadcast to the Host determined?

    Here's a copy of the referenced section of the TRD:

    16.5 Broadcasts to Smart Charger and Smart Battery Host

    If the [HPE] bit is enabled, MASTER mode broadcasts to the host address are PEC enabled. If the [CPE] bit is enabled, MASTER mode broadcasts to the smart-charger address are PEC enabled. The [BCAST] bit enables all broadcasts to a host or a smart charger. When the [BCAST] bit is enabled, the following broadcasts are sent:

     

    ChargingVoltage() and ChargingCurrent() broadcasts are sent to the smart-charger device address (Charger Address) periodically. The default period is set in Alarm Timer.

     • If any of the [OCA], [TCA], [OTA], [TDA], [RCA], [RTA] flags are set, the AlarmWarning() broadcast is sent to the host device address (Host Address) at the period set in SMB BCAST Time. Broadcasts stop when all flags above have been cleared.

     • If any of the [OCA], [TCA], [OTA], [TDA] flags are set, the AlarmWarning() broadcast is sent to a smartcharger device address at the period set in Charger Request Time. Broadcasts stop when all flags above have been cleared.

     

  • To add to my previous question, the Smart Battery Data Specification, Version 1.1, Page 40 states that the AlarmWarning() message should be broadcast to the SMBus Host at 10 second intervals. Is that what the bq78350-R1 does?

    5.4. Smart Battery Critical Messages

    Whenever the Smart Battery detects a critical condition, it becomes a bus master and sends AlarmWarning() messages to both the Smart Battery Charger and the SMBus Host, as appropriate, notifying them of the critical condition(s). The message sent by the AlarmWarning() function is the same as the message returned by the BatteryStatus() function, except for the lowest nibble (4 bits). The Smart Battery will continue broadcasting the AlarmWarning() messages at 10 second intervals until the critical condition(s) has been corrected. The Smart Battery may not begin broadcasting AlarmWarning() messages to either the SMBus Host or Smart Battery Charger for at least 10 seconds after it enters the “On State” as described in Section 4.4 ‘Smart Battery Characteristics.’

    Please define the contents of the AlarmWarning() message that's broadcast to the SMBus Host. Is it the same as the AlarmWarning() message defined in the Smart Battery Data Specification, Version 1.1?

     

    0x16 BatteryStatus(), is similar to the AlarmWarning() message defined in the Smart Battery Data Specification, Version 1.1, except for the added vendor specific meanings for the EC3:0 (Bit 3–0): Error Code. Is the contents of the AlarmWarning() message the same as 0x16 BatteryStatus()?

  • Please define the contents of the AlarmWarning() message that's broadcast to the SMBus Host. Is it the same as the AlarmWarning() message defined in the Smart Battery Data Specification, Version 1.1?

    0x16 BatteryStatus(), is similar to the AlarmWarning() message defined in the Smart Battery Data Specification, Version 1.1, except for the added vendor specific meanings for the EC3:0 (Bit 3–0): Error Code. Is the contents of the AlarmWarning() message the same as 0x16 BatteryStatus()?
  • Sheldon,
    Apparently, the SMB BCAST Time was removed from the firmware and the device uses the Charger Request Time to set the rate to broadcast faults to the host. The ChargingCurrent and ChargingVoltage broadcasts are at a 10s rate, unless the gauge s servicing a higher priority event such as flash update, protection, etc. The BatteryStatus (AlarmWarning) message broadcast is the same as defined in the SBS spec. The EC3:0 bits report errors that occur in firmware to help TI diagnose issues.
    Tom