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.

TMS320F28379D: unable to observe the TX output

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello Team,

We recently purchased a Delfino TMS320f28379D Launch XL dev board. I am unable to observe the TX output from SCI echoback example project imported from C2000ware onto CCS v7.2.0.

My present setup includes the delfino board with a CP210x USB-UART converter connected to a comm port terminal application.

I have tried changing the UART pins to GPIO18(Tx)-GPIO19(Rx) (mux 2) i.e PINS3,4 on J1 header also GPIO139(Rx)-GPIO56 (Tx)(mux 6) i.e Pins 43,44 on J5 header, and did not receive TX on the comm terminal application.

On debugging the application, I could observe the character sent in the SciaRegs.SCITXBUF register map view, but do not observe the same on probing the Tx pin with an oscilloscope.

Kindly let me know how to proceed.

Regards,

  • Hi 坑坑,

    This thread may be somewhat useful:
    e2e.ti.com/.../633864

    Have you tried setting both GPIO mux settings to 0, setting the GPIO direction to output, and then toggling the pin manually by manipulating the GPIODAT register to verify pin connections?

    Have you been able to see other module waveforms on the pins? e.g. you might run an ePWM example, find the output waveform, and then try moving that to a different mux position.

    Exactly what mux settings are your writing to change the SCI pins to GPIO18 and GPIO19?
  • Thank you for your reply.

    I have been able to toggle the pins (18,19) with mux setting 0 and was also observe the PWM waveforms with the mux setting 5 accordingly.

    However, the SCI problem still persists.

    The sci_echoback example code has pins 28 (Rx), 29 (Tx) configured for SCI, I have changed them to 18 (Tx), 19 (Rx) with mux setting 2 as shown in the data sheet (attached).

    // GPIO_SetupPinMux(28, GPIO_MUX_CPU1, 1);
    // GPIO_SetupPinOptions(28, GPIO_INPUT, GPIO_PUSHPULL);
    // GPIO_SetupPinMux(29, GPIO_MUX_CPU1, 1);
    // GPIO_SetupPinOptions(29, GPIO_OUTPUT, GPIO_ASYNC);

    GPIO_SetupPinMux(19, GPIO_MUX_CPU1, 2);
    GPIO_SetupPinOptions(19, GPIO_INPUT, GPIO_PUSHPULL); //Rx
    GPIO_SetupPinMux(18, GPIO_MUX_CPU1, 2);
    GPIO_SetupPinOptions(18, GPIO_OUTPUT, GPIO_ASYNC); //Tx


    I have tried changing the pins to the FTDI pins (43,42) to receive data on mini usb programming cable, which results in junk values being printed on Hyperterminal.

    I have tried changing the clock settings in the InitSysCtrl function:

    #ifdef _LAUNCHXL_F28379D
    InitSysPll(XTAL_OSC,IMULT_40,FMULT_0,PLLCLK_BY_2); // #define _LAUNCHXL_F28379D 1
    #else
    InitSysPll(XTAL_OSC, IMULT_20, FMULT_0, PLLCLK_BY_2); // default setting as per example
    #endif // _LAUNCHXL_F28379D

    But it doesn’t seem to make a difference.

    The Baud rate is Mapped to 200 Mhz SYSCLK by default in the example:

    // SCIA at 9600 baud
    // @LSPCLK = 50 MHz (200 MHz SYSCLK) HBAUD = 0x02 and LBAUD = 0x8B.
    // @LSPCLK = 30 MHz (120 MHz SYSCLK) HBAUD = 0x01 and LBAUD = 0x86.
    //
    SciaRegs.SCIHBAUD.all = 0x0002;
    SciaRegs.SCILBAUD.all = 0x008B;


    Regards,
    K.K
  • Hi K.K,

    The SCI echoback example is using SCI module A.  The image you pasted in shows that GPIO18 and GPIO19 can be the TX and RX for SCI module B.  

    You should be able to use SCI module B instead of A if you want to use these particular pins, but you will need to do some additional code changes to replace module A code with module B code instead.

    e.g. SciaRegs.SCICCR.all becomes ScibRegs.SCICCR.all

    Alternately, you should pick a different pin-out location for SCI module A.  

    ------

    That you got jibberish characters when you used the virtual COM port may indicate that there is also a baud rate issue.  It may be worth going back to that setting and debugging it before moving on to use your UART-USB bridge IC.

    ------

    Here is another recent post with baud rate issues that may be helpful  

    e2e.ti.com/.../637238