BQ40Z50: Assistance Needed with SMBus Communication Issue on BQ40Z50 using MSP430

Hi Freddie,

Just to confirm, in both the situation using the EV2400 and the MSP430, are they both being connected to the bq40z50 on a custom PCB and not the bq40z50EVM?

When communicating using the MSP430, can you please tell me the list of instructions that are being sent to gauge just to check?

Are there any differences in the routing of the SMBus lines or the pack connections when communicating with the MSP430 compared to the EV2400?

Regards,

Anthony Baldino

Hi Anthony,

Thank you for your prompt response and your inquiries. Below are the details you requested:

1. Confirmation of Setup: Yes, both the EV2400 and the MSP430 are connected to a custom PCB containing the bq40z50, not the bq40z50EVM.

2. List of Instructions: Here is a snippet of the sample code used to communicate with the bq40z50 using the MSP430:
   

   I2C_Master_ReadReg(0x0B, 0x0A, 3);
   

   And here is the implementation of the I2C_Master_ReadReg function:

   I2C_Mode I2C_Master_ReadReg
   (
           uint8_t dev_addr,
           uint8_t reg_addr,
           uint8_t count
   )
   {
       /* Initialize state machine */
       MasterMode = TX_REG_ADDRESS_MODE;
       TransmitRegAddr = reg_addr;
       RXByteCtr = count;
       TXByteCtr = 0;
       ReceiveIndex = 0;
       TransmitIndex = 0;
   
       UCB2I2CSA = dev_addr;
       UCB2IFG &= ~(UCTXIFG + UCRXIFG);       // Clear any pending interrupts
       UCB2IE &= ~UCRXIE;                       // Disable RX interrupt
       UCB2IE |= UCTXIE;                        // Enable TX interrupt
   
       UCB2CTLW0 |= UCTR + UCTXSTT;             // I2C TX, start condition
       __bis_SR_register(LPM0_bits + GIE);              // Enter LPM0 w/ interrupts
   
       return MasterMode;
   }
   
   
   //******************************************************************************
   // I2C Interrupt ***************************************************************
   //******************************************************************************
   #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
   #pragma vector = USCI_B2_VECTOR
   __interrupt void USCI_B2_ISR(void)
   #elif defined(__GNUC__)
   void __attribute__ ((interrupt(USCI_B2_VECTOR))) USCI_B2_ISR (void)
   #else
   #error Compiler not supported!
   #endif
   {
       switch(__even_in_range(UCB2IV, USCI_I2C_UCBIT9IFG))
       {
       case USCI_NONE:                         // Vector 0: No interrupts
           break;
       case USCI_I2C_UCALIFG:                  // Vector 2: ALIFG
           break;
       case USCI_I2C_UCNACKIFG:                // Vector 4: NACKIFG
           UCB2CTL1 |= UCTXSTP; // Send I2C stop condition
           UCB2IFG = 0;
           break;
       case USCI_I2C_UCSTTIFG:                 // Vector 6: STTIFG
           break;
       case USCI_I2C_UCSTPIFG:                 // Vector 8: STPIFG
           break;
       case USCI_I2C_UCRXIFG3:                 // Vector 10: RXIFG3
           break;
       case USCI_I2C_UCTXIFG3:                 // Vector 12: TXIFG3
           break;
       case USCI_I2C_UCRXIFG2:                 // Vector 14: RXIFG2
           break;
       case USCI_I2C_UCTXIFG2:                 // Vector 16: TXIFG2
           break;
       case USCI_I2C_UCRXIFG1:                 // Vector 18: RXIFG1
           break;
       case USCI_I2C_UCTXIFG1:                 // Vector 20: TXIFG1
           break;
       case USCI_I2C_UCRXIFG0:                 // Vector 22: RXIFG0
           rx_val = UCB2RXBUF;
           if (RXByteCtr)
           {
               ReceiveBuf[ReceiveIndex++] = rx_val;
               RXByteCtr--;
           }
           if (RXByteCtr == 1)
           {
               UCB2CTLW0 |= UCTXSTP;
           }
           else if (RXByteCtr == 0)
           {
               UCB2IE &= ~UCRXIE;
               MasterMode = IDLE_MODE;
               __bic_SR_register_on_exit(CPUOFF);      // Exit LPM0
           }
           break;
       case USCI_I2C_UCTXIFG0:                 // Vector 24: TXIFG0
           switch (MasterMode)
           {
               case TX_REG_ADDRESS_MODE:
                   UCB2TXBUF = TransmitRegAddr;
                   if (RXByteCtr) {
                       MasterMode = SWITCH_TO_RX_MODE;   // Need to start receiving now
                   } else {
                       MasterMode = TX_DATA_MODE;        // Continue to transmision with the data in Transmit Buffer
                   }
                   break;
   
               case SWITCH_TO_RX_MODE:
                   UCB2IE |= UCRXIE;              // Enable RX interrupt
                   UCB2IE &= ~UCTXIE;             // Disable TX interrupt
                   UCB2CTLW0 &= ~UCTR;            // Switch to receiver
                   MasterMode = RX_DATA_MODE;    // State state is to receive data
                   UCB2CTLW0 |= UCTXSTT;          // Send repeated start
                   if (RXByteCtr == 1)
                   {
                       //Must send stop since this is the N-1 byte
                       while((UCB2CTLW0 & UCTXSTT));
                       UCB2CTLW0 |= UCTXSTP;      // Send stop condition
                   }
                   break;
   
               case TX_DATA_MODE:
                   if (TXByteCtr)
                   {
                       UCB2TXBUF = TransmitBuf[TransmitIndex++];
                       //EUSCI_A_UART_transmitData(EUSCI_A3_BASE, UCB0TXBUF);
                       TXByteCtr--;
                   }
                   else
                   {
                       //Done with transmission
                       UCB2CTLW0 |= UCTXSTP;     // Send stop condition
                       MasterMode = IDLE_MODE;
                       UCB2IE &= ~UCTXIE;                       // disable TX interrupt
                       __bic_SR_register_on_exit(CPUOFF);      // Exit LPM0
                   }
                   break;
   
               default:
                   __no_operation();
                   break;
           }
           break;
       default:
           break;
       }
   }

   This code initiates a read operation from register 0x0A (pack current) on the bq40z50 with a data length of 3 bytes.

3. Comparison of SMBus Lines and Pack Connections: The routing of the SMBus lines (SCL, SDA) and the pack connections remains consistent between the MSP430 and the EV2400 setups. Both utilize the same connections - SCL, SDA, and GND (VSS).

   
   Please let me know if you require any further information or if there are additional steps we can take to diagnose and resolve the issue.

   Best regards,
   
   Freddie Jheng

Hi Freddie,

Thank you for sending that information over. Above, you say that when the MSP430 is reading out the pack current, the measured current is still around 450mA. Was this measurement taken from measuring the sense resistor attached to SRN and SRP? This sense resistor is what the gauge relies on for its current measurements.

Can you also tell me if there had been any current calibration that had been done to the gauge?

Regards,

Anthony Baldino

Hi Anthony,

Thank you for your follow-up questions. Here are the clarifications you requested:

1. Clarification on Current Measurement: Yes, the measurement of around 450mA obtained when the MSP430 is reading out the pack current was indeed taken from measuring the sense resistor attached to SRN and SRP. This sense resistor is integral for the gauge's current measurements.

2. Information on Current Calibration: Regarding current calibration, I have only utilized TI tools, specifically Battery Management Studio along with EV2400, to perform the calibration. When the oscilloscope shows a reading of 450mA, I input this value into the current calibration box within Battery Management Studio and subsequently push the "Calibrate Gas Gauge" button.

In light of these points, my curiosity lies in understanding why the BQ40z50 may reply with different values despite utilizing the same hardware (custom PCB) and the same SMBus pattern. Are there any factors or considerations that I might have overlooked?

Your insights and guidance on this matter would be greatly appreciated.

Best regards,

Freddie Jheng

Hi Anthony,

Thank you for your continued support and suggestions. Based on your latest inquiry, I have conducted further investigation and made some observations:

1. MCU Initialization: I can confirm that during MCU initialization, no commands are being sent to the BQ40Z50. However, there is another IC on the same SMBus, the BQ25798, with address 0x6B, which undergoes initialization.

2. Initialization of BQ25798: Here is a snapshot of the initialization sequence for the BQ25798:

   

3. Current and Current Offset Configuration: In the PCB configuration, the resistor value for current sensing is 10 ohms. Below is a figure depicting the current and current offset:

   

Considering these points, I wonder if there are any configurations that need to be adjusted to ensure proper communication with both the BQ25798 and the BQ40Z50 on the same SMBus. Despite performing a power-on reset, the issue persists.

Could you please advise if any configuration changes are necessary in this scenario?

Looking forward to your insights.

Best regards,
Freddie Jheng

Hi Freddie,

Thank you for sharing the information regarding the MCU and the calibration values. I do not believe that the bq27598 should cause any issues regarding the communication.

Just to check, can you please read the firmware version of the gauge from both the MCU and EV2400 just to confirm this is not a problem with the SMBus lines? The value should be the same when read from both.

Regarding the MCU, is this a part of the custom board the bq40z50 is on or is it an off board connection? If possible, can you please send the schematic so we can take a deeper look into what could be causing the current difference?

Regards,

Anthony Baldino

Hi Anthony,

Thank you for your prompt response and suggestions. Here are the updates and additional information regarding our setup:

1. Firmware Version: While I'm uncertain about the firmware version of the MCU, I can confirm that the BQ40Z50 has been updated from R1 to R3, as shown in Figure 1.
   
    Figure 1.

2. Introduction of MCU Connection: The MCU PCB is connected to the BQ40Z50 PCB via CN42, which connects to CN8 on the BQ40Z50 PCB. Additionally, SDA and SCL are pulled up to 3.3V

   • Figure 2: Block diagram of the BQ40Z50 PCB
   • Figure 3: Schematic of the BQ40Z50 PCB
   • Figure 4, 5: Schematic of the MCU PCB
     
     
     
     Figure 2.
     
     Figure 3.
     
     
     Figure 4.
     
     
     Figure 5.
     
     

Please let me know if you require any further details or if there are specific areas you would like us to focus on for troubleshooting.

Looking forward to your guidance.

Best regards,

Freddie Jheng

Hi Freddie,

Thank you for sending those schematic files over. Regarding the sense resistor formation, I have a couple questions:

Can you please tell me the purpose of the C328 capacitor above the sense resistor? Normally, in our schematics for the bq40z50EVM, this capacitor is placed above the R592 and R593 connections seen below:

Can you also please confirm that GND_BMC1_BP1 and GND_BMC_PCU are tied to the negative side of the battery stack and the negative side of the pack connection (PACK-)?

In the document below, the schematic images for the EV2400 can be found on page 15. I believe this can be useful in comparing how your custom MCU and the EV2400 communication lines match up.

https://www.ti.com/lit/pdf/sluu446

Regards,

Anthony Baldino

Thank you for your inquiries and for providing additional guidance. Here are the clarifications and updates regarding your questions:

1. Purpose of Capacitor C328: C328 is indeed intended to serve as the bias capacitor to the power source, similar to the placement of capacitors C8 and C10 in the bq40z50EVM schematics.

2. Confirmation of Ground Connections: Both GND_BMC1_BP1 and GND_BMC_PCU are indeed connected to the negative side of the battery stack and the negative side of the pack connection (PACK-).

3. Comparison of MCU and EV2400: Thank you for providing the EV2400 schematic. Our current MCU is the MSP430FR5994, while the EV2400 uses the MSP430F5529. In our setup, I have configured the FR5994's P7.0 and P7.1 in I2C mode to simulate SMBus communication. However, the F5529's P4.6 and P4.7 are designated as general I/O. It appears that the SMBus communication is emulated using software. Could you kindly provide the software SMBus code for general I/O?

Thank you once again for your assistance and support. Your insights and guidance are invaluable in resolving this issue.

Best regards,

Freddie Jheng

Hi Freddie,

Enshuo Jheng said:

Comparison of MCU and EV2400: Thank you for providing the EV2400 schematic. Our current MCU is the MSP430FR5994, while the EV2400 uses the MSP430F5529. In our setup, I have configured the FR5994's P7.0 and P7.1 in I2C mode to simulate SMBus communication. However, the F5529's P4.6 and P4.7 are designated as general I/O. It appears that the SMBus communication is emulated using software. Could you kindly provide the software SMBus code for general I/O?

I do not believe I am able to share the code of the EV2400's SMBus code, however if the MSP430 you are using is able to read the data from the gauge without getting a NACK, I do not believe this is the issue.

If possible, would you be able to test the connection points of CN8 in the schematic above (for the EV2400/MCU connection) and see if there is any large difference of voltage or current when each the EV2400 and the MCU is connected?

Regards,

Anthony Baldino

Hi Anthony,

I believe I've identified the current problem. Upon further examination, I discovered that both GND_BMC1_BP1 and GND_BMC1_SYS are connected together. This configuration results in current division before passing through RS19 and reaching GND_BMC1_BP1.

This realization likely explains the discrepancy we've been encountering in our current readings.

Thank you once again for your continued support and guidance throughout this troubleshooting process.

Best regards,
Freddie Jheng