- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hello Forum
I am attempting to make a battery management system using the BQ76PL536EVM-3 and MSP-EXP430F5529LP, using the application report SLAA478.
So far, I've removed resistors R49, R53 and R60 from the 'PL536, and I have modified the software available to use P1.5 instead of P1.1 (on the MSP430 LP) for the FAULT signal from the 'PL536.
However, when everything is connected, I am not seeing any data being sent to the host PC via USB (verified using PuTTY). In fact, using CCS, I am not seeing the any of the 3 bq76PL536 devices being assigned an address in the code.
What does happen, however, is that the red LED on the MSP430 LP (P1.1) switches on and stays on (implying a connection/communication problem between the MSP and BQ). Also, some cells connectd to the 'PL536 EVM seem to be discharging through their balancing resistors, even though their voltages are lower than the other cells in the pack.
Has anyone experienced this? Does anyone have a solution?
Thanks for checking the connections. Let's try using the backchannel UART on the MSP-EXP430F5529LP, which means commenting out the USB portions and uncommenting the UART portions in the 'main.h' file. Since you're using the LaunchPad, I'd change the original UART pins shown in Table 6 in SLAA478 to be the pins mentioned in Section 2.2.6 in the LaunchPad's User's Guide. You may also have to refer to the schematic or quick user's guide for the specific pin names. Keep in mind the proper RX -> TX and TX -> RX connections.
Let me know if this allows you to communicate with the device.
Regards,
James
MSP Customer Applications
Hello James
I tried your suggestion.
Just commenting out the USB sections of code in ‘main.h’ and uncommenting the UART sections did not solve the problem. The same thing happens.
When the program is running, suspending it consistently places the cursor within two functions: ‘spi_read_reg’ or ‘bq_pack_address_discovery’. These functions seem to be where the program is stuck/looping.
For the second suggestion, the backchannel UART pins on the F5529 are pins P4.4 (TX) and P4.5 (RX).
These are connected via jumpers to the ez-FET lite. Still, I made the changes from P3.3 and P3.4, to P4.4 and P4.5, respectively, in the ‘UART.h’ file. Still no change; the same thing happens. This is using the USB A to micro USB cable that came with the LaunchPad.
Also, do these changes influence communications between the 'PL536 and LaunchPad? If I'm not mistaken, these devices use SPI to communicate, so any changes to UART should not affect the two.
Regards
Let me know if you figure out what's causing the error. There shouldn't be a conflict between the UART and SPI interfaces, but maybe I'm missing something.
In the meantime, I modified the 'MSP430F55xx_uscia0_uart_01.c' code example to utilize the backchannel UART, so you can make sure that portion of the application works correctly. In Putty, I turned (forced) off the local echo and local line editing, updated the correct COM port to match the "MSP Application Interace" UART port, updated the baud rate to 115200, and saved the profile in Putty as "MSP430F5529" for easier loading in the future.
In the code below, I commented out Line 107 to demonstrate that a unique value was indeed coming from the MSP430. In this configuration, after programming the board and stopping debug, and opening your saved session in Putty, you can type anything, and the MSP430 will send back "h", since this is hard-coded in Line 108 as "0x68" in hexadecimal. If you uncomment Line 107 and comment out Line 108, then whatever you type in the Putty terminal will be sent back from the MSP430. Also, LED1 will blink dimly (since it happens so quickly) on the LaunchPad, signifying that the UART ISR has been executed.
/* --COPYRIGHT--,BSD_EX
* Copyright (c) 2012, Texas Instruments Incorporated
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* * Neither the name of Texas Instruments Incorporated nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*******************************************************************************
*
* MSP430 CODE EXAMPLE DISCLAIMER
*
* MSP430 code examples are self-contained low-level programs that typically
* demonstrate a single peripheral function or device feature in a highly
* concise manner. For this the code may rely on the device's power-on default
* register values and settings such as the clock configuration and care must
* be taken when combining code from several examples to avoid potential side
* effects. Also see www.ti.com/grace for a GUI- and www.ti.com/msp430ware
* for an API functional library-approach to peripheral configuration.
*
* --/COPYRIGHT--*/
//******************************************************************************
// MSP430F552x Demo - USCI_A1, 115200 UART Echo ISR, DCO SMCLK
//
// Description: Echo a received character, RX ISR used. Normal mode is LPM0.
// USCI_A1 RX interrupt triggers TX Echo.
// Baud rate divider with 1048576hz = 1048576/115200 = ~9.1 (009h|01h)
// ACLK = REFO = ~32768Hz, MCLK = SMCLK = default DCO = 32 x ACLK = 1048576Hz
// See User Guide for baud rate divider table
//
// MSP430F552x
// -----------------
// /|\| |
// | | |
// --|RST |
// | |
// | P4.4/UCA1TXD|------------>
// | | 115200 - 8N1
// | P4.5/UCA1RXD|<------------
//
// Bhargavi Nisarga
// Texas Instruments Inc.
// April 2009
// Built with CCSv4 and IAR Embedded Workbench Version: 4.21
//******************************************************************************
#include <msp430.h>
int main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= BIT0; // P1.0 = LED1
P1OUT &= ~BIT0; // Turn LED1 off
P4SEL |= BIT4+BIT5; // P4.4,5 = USCI_A1 TXD/RXD
UCA1CTL1 |= UCSWRST; // **Put state machine in reset**
UCA1CTL1 |= UCSSEL_2; // SMCLK
UCA1BR0 = 9; // 1MHz 115200 (see User's Guide)
UCA1BR1 = 0; // 1MHz 115200
UCA1MCTL |= UCBRS_1 + UCBRF_0; // Modulation UCBRSx=1, UCBRFx=0
UCA1CTL1 &= ~UCSWRST; // **Initialize USCI state machine**
UCA1IE |= UCRXIE; // Enable USCI_A1 RX interrupt
__bis_SR_register(LPM0_bits + GIE); // Enter LPM0, interrupts enabled
__no_operation(); // For debugger
}
// Echo back RXed character, confirm TX buffer is ready first
#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=USCI_A1_VECTOR
__interrupt void USCI_A1_ISR(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(USCI_A1_VECTOR))) USCI_A1_ISR (void)
#else
#error Compiler not supported!
#endif
{
switch(__even_in_range(UCA1IV,4))
{
case 0:break; // Vector 0 - no interrupt
case 2: // Vector 2 - RXIFG
P1OUT = BIT0; // Turn LED1 on
while (!(UCA1IFG&UCTXIFG)); // USCI_A1 TX buffer ready?
//UCA1TXBUF = UCA1RXBUF; // TX -> RXed character
UCA1TXBUF = 0x68; // TX -> RXed character
P1OUT &= ~BIT0; // Turn LED1 off
break;
case 4:break; // Vector 4 - TXIFG
default: break;
}
}
Regards,
James
MSP Customer Applications
This is what appears when I try to build the original program ('main.c'):
The first time when I tried building the program, and it failed, the file 'TI_USCI_SPI_Regs.h' has the mini yellow triangle next to it. Whenever I try building again to look for the errors, that triangle does not appear anymore.
EDIT:
Restarted the program, and the warnings appeared again:
Hi Raheem,
What version of CCS are you using? I'm asssuming (and also using) CCS v7. I downloaded the code and tried to build it, but I encountered an error pointing to 'usb.c'. Keep in mind I didn't make any changes to any other files. After removing "UPCS0 + " from Line 336, the code built without any errors. I found this solution in this thread.
Next, I'll try to make the same changes as you to see if I can duplicate your errors.
Regards,
James
MSP Customer Applications
Hi Raheem,
Good job resolving those build errors! Maybe another project/workspace was affecting it somehow. In CCS, I generally keep a separate workspace for each project, and also when I import a project into CCS, I make sure to check the "Copy projects into workspace" option before finishing the import process. This way, it copies the original project into the workspace, so if necessary, you can delete the workspace without deleting the original project.
Now, after programming the LaunchPad with the code changed to UART communication, LED1 (P1.0) is ON. However, after looking through SLAA478 to see what this means, I noticed that the signals/pins in Figure 1 do NOT match those listed in Table 1. Looking at the #defines in the 'bq_pack.h' file, the signals in the code match the pin descriptions in Table 1. I'll submit feedback to get Figure 1 updated accordingly.
Back to P1.0, this is defined as the "OUT_BQ_LED" in 'bq_pack.h'. In 'main.c', I put a breakpoint at Line 155. In this while() loop, LED1 (P1.0) is turned on if the BQ devices are not discovered, which makes sense because I don't have the BQ EVM or have it connected. Thus, the code never gets to the point where it can send information to the terminal.
Regards,
James
MSP Customer Applications
Hello James
By switching back to USB CDC from UART, I assumed you meant enabling USB comms in 'main.h', and reverting back to previous UART settings in 'UART.h'. This is what I did. Next, I disconnected and reconnected the LaunchPad, but there was no pop-up asking for a driver. However, in Device Manager, this is what I am seeing:
I assume that the presence of USB Serial Device (COM5) under Ports means that the driver is already installed. I have never been prompted for it, however, so perhaps it may have been automatically installed?
Regarding the while() loop in 'main.c', I am unable to get past that loop. LED1 turns on, and the delay occurs, then the cycle repeats itself. I believe this may be sufficient indication that there is damage to the isolated communications interface on the EVM.
Regards
Raheem Hall said:By switching back to USB CDC from UART, I assumed you meant enabling USB comms in 'main.h', and reverting back to previous UART settings in 'UART.h'. This is what I did.
Correct. I didn't change anything in 'UART.h', since changing the #define in 'main.h' to "USB_COMM" uses 'usb.h' instead.
Raheem Hall said:Next, I disconnected and reconnected the LaunchPad, but there was no pop-up asking for a driver. However, in Device Manager, this is what I am seeing:
This is strange. Perhaps it's because I'm using Windows 7 and you're using Windows 8 or 10. When I changed back to USB_COMM and connected the LaunchPad, that's when the pop-up was displayed. After going to Device Manager, I found the USB CDC under "Other devices". Clicking on it and re-configuring the driver, the LaunchPad now shows up as Virtual COM port in Device Manager now. If you've configured your code for USB_COMM and reprogrammed the board and you're still seeing it as USB Serial Device (COM5), I'd try manually re-configuring that driver with the 'MSP430_CDC.inf' file.
Raheem Hall said:Regarding the while() loop in 'main.c', I am unable to get past that loop. LED1 turns on, and the delay occurs, then the cycle repeats itself. I believe this may be sufficient indication that there is damage to the isolated communications interface on the EVM.
If you aren't able to get past the while() loop, it doesn't seem like the single device can be found over SPI, which is strange if the boards are connected properly. However, if the board is damaged, this would make sense. Hopefully you can obtain a working BQ EVM.
Regards,
James
MSP Customer Applications
Hello James
Using UART Communications, there was activity at the COM Port, verified using PuTTY. The only message that was sent from the MSP430 to the host PC was "The battery pack is in INITIAL_MODE Mode."
Next, I decided to attempt create a GUI using GUI Composer V2 on the cloud, since I am using CCS v7. I uploaded the project to my CCS Cloud, then programmed the MSP430 from there. This time, after connecting to the COM port via CCS Cloud, I saw actual cell voltage data being sent to the host PC. But then, the system entered ALERT mode, and LED1 on the LaunchPad remained on. I ran the program again, and the same thing happened, except some cell voltage data were irregular, reading over 25V. I ran the program again, and then it put me pack to square one; the only message being transmitted was again, "The battery pack is in INITIAL_MODE Mode" :
I stepped through the program to see what really happens. I found that it never gets to the UARTCommunicationTask() function (line 567 in 'main.c'). All that happens is it gets to the Timer1SecExpiredTask() function (line 277 in 'main.c'), and inside that function, there is another function, bq_pack_start_conv(). This function takes the program to 'spi_if.c' to a function spi_write_reg(), which runs 4 times. The program then returns to 'main.c', at the end of the main() function.
Since UART communications were not working, I decided to revert back to USB communications. CCS Cloud was unable to open the terminal to the COM Port for the USB Serial Device, so I could not see if anything was actually being transmitted. Nevertheless, I stepped through the code to see what was happening.
When the program got to the USBCommunicationTask() function (line 701 in 'main.c'), it entered the case ST_ENUM_ACTIVE in the switch case, then proceeded to the default action, which is nothing. The program then returned to the low power mode to await the next interrupt from the 1 second timer.
Do you have any idea what may be causing these issues? I am still using the damaged EVM while I await delivery of the new EVM - is this likely to be the reason?
EDIT:
As I finished typing that, there was an update in the terminal. This is what I can see now:
LED1 is still blinking though, implying that there is still communication, and the pack is not actually in alert mode. That update above has been the only one in about 15 minutes.
Regards
**Attention** This is a public forum
