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.

MSP-EXP430FR5994: Spurious UART receive

Part Number: MSP-EXP430FR5994
Other Parts Discussed in Thread: BQ79616, MSP430FR5994, MSP430WARE

Please review the MSP430 UART receive. The receive interrupt is triggering too early and data received is incorrect.

 

  • A description of your full hardware setup – what boards are you using, how is everything connected to each other, how are you connected to the PC?

 

PC -> MSP-EXP430FR5994 EUSCIA1UART -> BQ79600-EVM -> custom BQ79616

 

  • How are you monitoring the system to view the result?

Breakpoint at:

   ReadReg(0, 0x2001, autoaddr_response_frame, 1, 0, FRMWRT_SGL_R);

Stepping into this line goes into the UART ISR right away instead of the functions below ReadReg. Only one byte is received, and it is not correct. After this byte, uart ISR does not trigger.

  • A description of the steps/procedures you took to get to the test example, your expectations of what should happen, and then what you’re actually seeing

BQ79600 should return 7 bytes in response to the ReadReg 0x2001 command. Address returned should be 0x14 on byte 5.

 

  • Lastly, what steps have you taken for debugging this so far?

In addition to watching variables/register contents on CCS IDE, I have scope probes on BQ79600 EVM Uart RX and TX.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*
* uartCommands.c
*
* Created on: Apr 21, 2022
* Author: Priya.Nadathur
*/
#include <driverlib.h>
#include <string.h>
#include "bspFuncs.h"
#include "mbbConfig.h"
#include "uartCommands.h"
#include "timer.h"
#include "B0_reg.h"
#ifdef BQ_UART
// CRC16 TABLE
// ITU_T polynomial: x^16 + x^15 + x^2 + 1
const uint16_t crc16_table[256] = { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301,
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Priya,

    Could you reduce the amount of provided code to a minimum that still demonstrates the issue?\

    Could you also show the main code around where you set your breakpoint?

    Thank you

  • What do the scope traces look like? Is the 0x55 real?

  • I uploaded a scaled down project with only the BQ initialization sequence (wake up, auto address) With this project, the UART Rx ISR is not triggering at all. I do see one BQ response on the scope.  The code related to all uart commands (with the BQ wrapper) is also in this post. Maybe the larger project had a different trigger for UART receive, I don't know what.  I can see that the OE error flag is set from the register contents. There is some byte in the Uart Rx and Tx buffers.

  • The breakpoint is set at line 122 of BQUartInitFuncs.c in my upload today (BQInitUartJun142022.zip). Please let me know if you have all the needed information.

  • Hi Priya,

    I am currently reading through your code to find the issue. As I am reading, I wanted to point out that I do not see where you are enabling the UART RX interrupt. I see that you enable global interrupts, but I can not find your enable for UART RX interrupts. Please verify that you do perform this step, as it is critical to enter the ISR you've written for receives.

    I see in your recent reply that when you hit your breakpoint that you've set, the UCOE flag of the UCA1MCTLW register is set, along with the UCRXERR flag. These two flags will be set whenever there is a character loaded into the UCA1RXBUF before the previous character has been read. More information on these flags can be found in section 30 of the MSP430FR58xx, MSP430FR59xx, and MSP430FR6xx Family User's Guide (linked below), and specific information about the flags can be found in Table 30-1.

    MSP430FR58xx, MSP430FR59xx, and MSP430FR6xx Family User's Guide (Rev. P) (ti.com)

    Please verify the above information as soon as possible as I continue to look for potential errors in your project.

  • Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void UART_Init(void){
    GPIO_setAsPeripheralModuleFunctionInputPin(
    BQUART_TX_PORT,
    BQUART_TX_PIN + BQUART_RX_PIN,
    BQUART_SELECT_FUNCTION
    );
    BQUART_initParam param = {0};
    param.clockPrescalar = 4,
    param.firstModReg = 0,
    param.secondModReg = 0,
    param.selectClockSource = BQUART_CLOCKSOURCE;
    param.parity = BQUART_PARITY;
    param.msborLsbFirst = BQUART_BITORDER;
    param.numberofStopBits = BQUART_STOPBIT;
    param.uartMode = BQUART_MODE;
    param.overSampling = BQUART_OVERSAMPLING;
    if(STATUS_FAIL == BQUART_INIT(BQUART, &param))
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I enable the UART Rx interrupt in the UART_Init function. I call the UART_Init before the auto address. Do I need to do this in more places?

    I did clean up my workspace and import the CCS project. The BQInit roject has the same behavior as the larger BQ project. The UART ISR triggers once receiving an incorrect byte and then not anymore.

    FYI-- I uploaded the BQInit project with recent minor edits. I kept the same project name. Please get a latest download when looking at this project, thanks.

  • Looking at your code it appears that you expect no data until you are ready for it. But it seems that isn't happening.

    What I see is: 1) Initialize UART and enable receive interrupt.

    2) Set idx =0;

    3) Send command.

    4) Expect data.

    The problem is that your code will process received data before the command is sent. It doesn't even check to make sure the index doesn't run past the end of the array. Sure it sets a flag but it doesn't disable RXIE and will keep storing data and incrementing idx. Writing over whatever lies beyond.

    Even if no data is expected you must code defensively.

  • I made the following changes to the uart send and ISR. There is no change in the receive data.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void uartSend(int length, uint8_t * data){
    uint8_t i;
    idx = 0;
    rxComplete = 0;
    BQUART_IE |= UCRXIE;
    for (i = 0; i < length; i++){
    while (!(UCA1IFG & UCTXIFG));
    BQUART_TXBUF = data[i];
    }
    }
    #pragma vector=BQUART_VECTOR
    /*******************************************************************************
    USCI_A1_ISR ******************************************************************
    *******************************************************************************
    * Function: A1 Interrupt Routine
    ********************************************************************************/
    __interrupt void BQUART_ISR(void)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If I put a breakpoint at the very end of uartSend, I can see BQ receive activity on the scope, though I don't exactly know what bytes are coming in. The timing of the ISR is not capturing this receive data. I need more pointers on what to do here.

  • You mentioned breakpoints. What is your "normal" test case? Do you let it run with no breakpoints?

    I ask since, if you set a breakpoint at the end of uartSend, you will (for that test run) lose all of the (BQ-side) Tx data since the MSP-side UART (SMCLK) is stopped while you're at the breakpoint.

    (Perhaps this is obvious, but someone has to ask.)

    Unsolicited: Don't clear RXIFG explicitly in the ISR -- it has already been cleared by reading the IV, and it will be cleared (again) by reading RXBUF. The symptom would be the loss of one out of each pair of bytes, which is not your symptom (yet).

  • I removed clearing RXIFG from the uart ISR. The only breakpoint in the test run is at 

    //OPTIONAL: read register address 0x2001 and verify that the value is 0x14
    ReadReg(0, 0x2001, autoaddr_response_frame, 1, 0, FRMWRT_SGL_R);

    This helps capture the BQ receive better. There is one BQ receive activity seen and then none after.

  • Hi Priya,

    For the BQ79600, can you capture a Salae/logic analyzer log and provide?  This will help us debug from the BQ79600 Rx side.  

    We are interested in the following....

    1. First we need to verify if the BQ79600 is waking up ( wake ping is working ) and BQ79600 is powered up.
    2. Scope shots to see the valid read request is sent from MCU to BQ79600  ( TX line ).
    3. Verify if the interrupt ( BQUART_ISR )  is configured properly to receive UART data.( MSP team should be able to verify the configuration ).
    4. Clear scope shot of what data is received on the RX line.

    Thanks,

    Tom

  • As I read this scope trace, the MCU is sending (yellow line) repeatedly, but only gets a response (purple line) to the first request.

    3) The configuration looks fine. (Priya, I'm assuming you're using the same #-defines as over in the other thread (?).)

    [Edit: 3+) I don't know how the clocks are set, but the scope trace (eyeball accuracy) indicates 1usec bit time -> 1Mbps.]

  • Priya,

    After reviewing further, I have two notes for you:

    1) This may be obvious, but to be sure, in your UART_Init function, when the BQUART_Init function executes, if it fails, the function returns and your main code executes the same as if the BQUART_Init function passed. You've said the RX ISR executes once, so it seems that this function is passing, and executing the interrupt enables, but it might be wise to add an assert or some other check to ensure that this isn't failing and then your device tries communicating over UART anyways. Aside from this, I haven't found anything that is incorrect in your UART_Init function.

    2) In your configure_pins_BQUart function, I see that you put both Pins 2.5 and 2.6 in output mode. This may be an issue, as typically the approach to utilize your GPIO pins for their UART functionality does not involve changing the PxOUT bits associated with those pins. Pins 2.5 and 2.6 are UCA1TXD and UCA1RXD respectively, when utilizing their secondary module function. To put these pins into these secondary module functions, you must set bits 5 and 6 of P6SEL1, and clear bits 5 and 6 of P6SEL0. For reference on this, you may want to visit TI's resource explorer, and follow the path MSP430Ware -> Devices -> MSP430FR5xx_6xx -> MSP430FR5994 -> Peripheral Examples -> Register Level, and then select either MSP430FR599x_euscia0_uart_01.c, or MSP430FR599x_euscia0_uart_02.c.

    Let us know if any improvements occur when making these adjustments to the P2.5 and P2.5 settings. 

  • I hesitate to disagree with Dylan, but:

    1) EUSCI_A_UART_init (as of 3.80.07.00) never fails. I suppose it's still a good idea to crash or something if it does, but it's not relevant to this thread.

    2) To get SECONDARY function, you set the P2SEL1 bits and clear the P2SEL0 bits. [Ref data sheet (SLASE54C) Table 6-25].  GPIO_setAsPeripheralModuleFunctionInputPin does this correctly. As Table 6-25 note (2) points out, the GPIO direction setting is irrelevant with the EUSCI.

    In short: You don't need to change anything here.

  • BQWake.pdf

    Attached are the BQ Wakeup Pulse and green light; Uart Read frame request following ReadReg(0, 0x2001, autoaddr_response_frame, 1, 0, FRMWRT_SGL_R);

    I have incorporated feedback from all responses here about the uart isr. I assume it has been set up correctly. I have added the BQ transmit transaction scope picture.

    I will gather the logic analyzer data next.

  • BQWake.pdf

    Attached are the BQ Wakeup Pulse and green light; Uart Read frame request following ReadReg(0, 0x2001, autoaddr_response_frame, 1, 0, FRMWRT_SGL_R);

    I have incorporated feedback from all responses here about the uart isr. I assume it has been set up correctly. I have added the BQ transmit transaction scope picture.

    I will gather the logic analyzer data next.

    BQRX decoder--220615-132458.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Id,Time[ns],0:UART: RX/TX
    0,10000800.00000000000000000000,80
    1,10010800.00000000000000000000,00
    2,10020800.00000000000000000000,20
    3,10030800.00000000000000000000,01
    4,10040800.00000000000000000000,00
    5,10050800.00000000000000000000,25
    6,10060800.00000000000000000000,84
    7,10143800.00000000000000000000,B0
    8,10153800.00000000000000000000,03
    9,10163800.00000000000000000000,31
    10,10173800.00000000000000000000,FF
    11,10183800.00000000000000000000,83
    12,10193800.00000000000000000000,34
    13,10271000.00000000000000000000,B0
    14,10281000.00000000000000000000,03
    15,10291000.00000000000000000000,32
    16,10301000.00000000000000000000,FF
    17,10311000.00000000000000000000,83
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I am able to gather the BQ TX data and all uart transmit messages are correct. However the BQ TX is not showing up consistently anymore on the scope and I am not able to capture it using the logic analyzer. 

    I got the trigger settings correct now. The BQ Tx is actually the correct response. For some reason it is not reaching the MSP430 uart. I am able to save only the uart tx to a text file. I took a screenshot of the uart rx. 

  • BQWake.pdf

    Attached are the BQ Wakeup Pulse and green light; Uart Read frame request following ReadReg(0, 0x2001, autoaddr_response_frame, 1, 0, FRMWRT_SGL_R);

    I have incorporated feedback from all responses here about the uart isr. I assume it has been set up correctly. I have added the BQ transmit transaction scope picture.

    I will gather the logic analyzer data next.

    BQRX decoder--220615-132458.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Id,Time[ns],0:UART: RX/TX
    0,10000800.00000000000000000000,80
    1,10010800.00000000000000000000,00
    2,10020800.00000000000000000000,20
    3,10030800.00000000000000000000,01
    4,10040800.00000000000000000000,00
    5,10050800.00000000000000000000,25
    6,10060800.00000000000000000000,84
    7,10143800.00000000000000000000,B0
    8,10153800.00000000000000000000,03
    9,10163800.00000000000000000000,31
    10,10173800.00000000000000000000,FF
    11,10183800.00000000000000000000,83
    12,10193800.00000000000000000000,34
    13,10271000.00000000000000000000,B0
    14,10281000.00000000000000000000,03
    15,10291000.00000000000000000000,32
    16,10301000.00000000000000000000,FF
    17,10311000.00000000000000000000,83
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I am able to gather the BQ TX data and all uart transmit messages are correct. However the BQ TX is not showing up consistently anymore on the scope and I am not able to capture it using the logic analyzer. 

    I got the trigger settings correct now. The BQ Tx is actually the correct response. For some reason it is not reaching the MSP430 uart. I am able to save only the uart tx to a text file. I took a screenshot of the uart rx. I note that to keep getting a BQ response byte, I need to 

    Once I stopped putting a breakpoint in the UART ISR to track every incoming byte, the contents of RXData match the BQ response seen on the logic analyzer. I find I get consistent receive triggers when I use the default value for TX_HOLDOFF BQ register. Seems like the issue is resolved. If I run into difficulties when moving forward with development, I will start a new thread. Many thanks.

**Attention** This is a public forum