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.

BQ79616-Q1: UART read commands not working

Part Number: BQ79616-Q1
Other Parts Discussed in Thread: BQ79616,

Hello,

we are currently evaluating the BQ79616 cell monitor for use in our BMS products. I already have access to the documents under an NDA.

We intend to use a single device per board paired with a microcontroller (in the documentation described as "Multi-drop configuration") using UART.

  • Sending the ping signals seem to work (Shutdown-to-Active transition raises current consumption and Ping signal can be observed on the RX Pin and on the COMMH+- Pins)
  • Sending broadcast write commands also triggers communication on the COMMH+- Pins, so I assume that the command is successfully read from the UART receiver in the monitor IC
  • If I send a broadcast write to DEV_CONF[MULTIDROP_EN] = 1, the differential daisy chain communication no longer reacts to broadcast write commands as expected

Currenty, we are not able to receive any answers to read-commands from the IC. I sticked to the BQ79616-Q1 Software Design Reference guide for wakeup and auto-adressing (disabled multidrop) and also tried to enable multidrop and work with single device read/write commands only. So far we never observed any communication on the TX-Pin.

Are there any constraints on the functionality of the TX pin? And how is the multidrop configuration supposed to work? I couldn't find much information in the datasheet and assumed that it should be used with single device commands with device address 0x00.

Thanks for your help!

Steps we took to configure the device:

Stack-Mode

  1. Send wake ping
  2. Delay for shutdown to active transition
  3. Send dummy broadcast write OTP_ECC_TEST=0x00 {D0 03 4C 00 FC 24}
  4. Enable auto addressing mode by broadcast writing CONTROL1=0x01 {D0 03 09 01 0F 74}
  5. Setting the DIR0_ADDR {D0 03 06 00 CB 44}
  6. Broadcast write everything as a stack device first (COMM_CTRL=0x02) {D0 03 08 02 4E E5}
  7. Set device as base and top of stack (COMM_CTRL=0x01) {90 00 03 08 01 1D D2}
  8. Dummy broadcast read OTP_ECC_TEST to sync the DLL {C0 03 4C 00 F8 E4} (No answer from device)
  9. Sending more read commands (either broadcast read or single device read, also no answers from device)

Multidrop-Mode

  1. Send wake ping
  2. Delay for shutdown to active transition
  3. Send dummy broadcast write OTP_ECC_TEST=0x00 {D0 03 4C 00 FC 24}
  4. Send broadcast write DEV_CONF=0x74 (setting MULTIDROP_EN to 1, leave rest at reset value)
  5. Sending read commands (either broadcast read or single device read, no answers from device)
  • Hi Jonas,

    I will to help you resolve your problem.

    - Depending on which Revision of the device you have, the factory default single device address might be 0x00 or 0x01. Please try both.

    - When Addressing in Stack Mode:

                1. You should be writing broadcast dummy data 0x00 to Registers OTP_ECC_DATAIN1 (0x343) to OTP_ECC_DATAIN8 (0x34A)

                2. On Step No.7 you should set STACK_DEV and TOP_STACK for your last stacked device. This is assuming you are communicating through COMLx and COMHx pins. Otherwise Stack doesn't make sense. If your Hardware is configured in Multi-Drop mode, you cannot exercise stack mode.

              3. For Dummy read you should read registers OTP_ECC_DATAIN1 (0x343) to OTP_ECC_DATAIN8 (0x34A) (same registers as dummy write).

    There is a procedure in the BQ79616 device Datasheet, table 9-19:

     - When Addressign in Multi-Drop Mode:

             1. Broadcast Write to DEV_CONF register with data 0x74 to enable Multi-Drop config. This will Disable the VIF interface (COMH/COML pins). 

            - Here there is no need to Auto-Address since the local MCU will handle the address on the bus. The local MCU can use address 0x00 or 0x01 to read/write to the BQ device.

    Regards,

    Viktor.

        

  • Hello Victor,

    thank you for your detailed answer. Unfortunately, we have not been able to establish UART communication with the IC yet. We have now ordered an EVAL board to rule out any problems with our PCB design.