LAUNCHXL-F280049C: UART seems not sending data

Hi Yubin,

There are multiple switches that control the various GPIOs and UART pins on the board, please refer to the switch table in the user guide depending on your desired functionality.

S6 should be the only required switch to change, so please ensure that none of the code modifications altered the GPIO used for UART communication. In addition, you may want to verify with the original Fuel Level project if the UART transmission data on the GPIO 28/29 pins are present.

Also note that the pin numbering seen on the top of the board corresponds to pin numbers and not GPIO numbers

Regards,

Peter

Thanks Peter. 

The strange thing is it worked when I tested Fuel Level Sensor a week ago. I have a video to show it was working. But it didnot work when I tested a voltage sensor. Now I tried to repeat the Fuel Level sensor test, I got the same issue: only see data like "27, 117, 91" etc. So my raspberry pi did not receive any data from UART pin on launchxl-F280049c. 

                      Lauchxl-F280049c pin 44  (GPIO 29)-------> Raspberry pi's pin 10

                      Lauchxl-F280049c pin 43 (GPIO 28) ---------> Raspberry Pi's pin 8

                      GND pin 62                       ----------> Raspberry pi's pin 6. 

I always run xds debug probe first, I can see the data(adc value on A0 and A1) with different Fuel Level or Voltage, but when I swithed to use real pin, there is no data out. 

It seems the GPIO29 couldn't send data out, and I don't know how to make it work again. Even if the card is broken, I am trying to know what cause the problem. 

is there another way to test whether GPIO 29 (pin44) has data out? sci_ex4_echoback seems woking in debug probe, but is there way to run lookback or echoback with GPIO29  and GPIO 28 pins?

Edit: Here is my code to send data to Raspberry Pi

mydata[0] = 0;
mydata[1] = (myADC0Result0 >> 8) & 0xFF; // Gets the upper 8 bits
mydata[2] = myADC0Result0 & 0xFF; // Gets the lower 8 bits
SCI_writeCharArray(SCIA_BASE, (uint16_t*)mydata, 3);

Another Edit: I just have a new thought, I will do a test and let you know the result later. 

Hi Yubin,

Is the code a direct copy of the previously used code? Or did you manually update the code to revert it back? Perhaps something is still present from the new additions which is causing this.

If it's a direct copy of the previous code, then it sounds like perhaps something got damaged on the device. Can you verify that the voltage sensor did not exceed VDDA during the device operation, or that you have some means of clamping the output if it does? Exceeding VDDA on the MCU could damage the device and cause unpredictable behavior.

Also another thing to test would be to adjust the GPIOs for the UART since GPIO35/37 can also be used for UART to the XDS debugger. But do note that you will need to use cJTAG to connect (since TDI/TDO are shared by GPIO35/37)

Regards,

Peter

Thanks Peter. 

Now I remembered. I did use the code from sci_ex4_echoback, but I modified the pin setup code. The problem is my CCS crashed and I don't remember what I changed. I think I changed the pin type or pin mode for GPIO 28 and 29. I will try to figure it out. 

Hi Yubin,

If you can provide the sample code you are using, that will help to debug as well

Regards,

Peter

I think the problem is the debug probe works fine, I can see the uart data. but when I switch the S6 switch to BP, pin 44 (GPIO 29) has no output. 

I once read that program may use the pin setup for debug, not for the real pin. I didnot remember what setup config I used before. 

Here is a simple code. the project setup is the same as sci_ex4_echoback  exmaple. 

#include "driverlib.h"

#include "device.h"

#include <stdlib.h>

uint16_t loopCounter = 0;

void main(void)

{

    unsigned char *mydata;

    Device_init();

    Device_initGPIO();

    //

    // GPIO28 is the SCI Rx pin.

    //

    GPIO_setControllerCore(DEVICE_GPIO_PIN_SCIRXDA, GPIO_CORE_CPU1);

    GPIO_setPinConfig(DEVICE_GPIO_CFG_SCIRXDA);

    GPIO_setDirectionMode(DEVICE_GPIO_PIN_SCIRXDA, GPIO_DIR_MODE_IN);

    GPIO_setPadConfig(DEVICE_GPIO_PIN_SCIRXDA, GPIO_PIN_TYPE_STD);

    GPIO_setQualificationMode(DEVICE_GPIO_PIN_SCIRXDA, GPIO_QUAL_ASYNC);

    //

    // GPIO29 is the SCI Tx pin.

    //

    GPIO_setControllerCore(DEVICE_GPIO_PIN_SCITXDA, GPIO_CORE_CPU1);

    GPIO_setPinConfig(DEVICE_GPIO_CFG_SCITXDA);

    GPIO_setDirectionMode(DEVICE_GPIO_PIN_SCITXDA, GPIO_DIR_MODE_OUT);

    GPIO_setPadConfig(DEVICE_GPIO_PIN_SCITXDA, GPIO_PIN_TYPE_STD);

    GPIO_setQualificationMode(DEVICE_GPIO_PIN_SCITXDA, GPIO_QUAL_ASYNC);

    Interrupt_initModule();

    Interrupt_initVectorTable();

    SCI_performSoftwareReset(SCIA_BASE);

    SCI_setConfig(SCIA_BASE, DEVICE_LSPCLK_FREQ, 115200, (SCI_CONFIG_WLEN_8 |

                                                        SCI_CONFIG_STOP_ONE |

                                                        SCI_CONFIG_PAR_NONE));

    SCI_resetChannels(SCIA_BASE);

    SCI_resetRxFIFO(SCIA_BASE);

    SCI_resetTxFIFO(SCIA_BASE);

    SCI_clearInterruptStatus(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);

    SCI_enableFIFO(SCIA_BASE);

    SCI_enableModule(SCIA_BASE);

    SCI_performSoftwareReset(SCIA_BASE);

    for(;;)

    {

         mydata = "0123456789\0";

         SCI_writeCharArray(SCIA_BASE, (uint16_t*)mydata, 11);

        loopCounter++;

        DEVICE_DELAY_US(500000);

    }

}

In debug probe, I can see 0123456789, but when TX (pin44) connected with raspberry pi's UART RX (pin 10), there is not reading. LogicProbe showed no signal from pin 44. 

Do I need to use different name in setPin/PadConfig so that data would go to GPIO29 (pin44). I have tried to use 29 or GPIO_29_SCITXDA, etc, but not working. 

Thanks. 

Edit: since launchpad uses 16-bit, I assume the receiver in my raspberry pi would receive two 8 bit for one 16-bit, so I expected to see like 0 1 0 2 0 3 0  4 ..... Is this correct?

Problem solved. 

I think earlier I used GPIO_PIN_TYPE_PULLUP, but later I forgot about it, GPIO_PIN_TYPE_STD is wrong. 

Hi Yubin,

Good to hear this is resolved. I think you should also refer to SysConfig tool, which helps with code generation of the peripheral configuration, and it can be easier to catch some of these typos since configuration becomes abstracted through the SysConfig options

Regards,

Peter