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.

LAUNCHXL-F28379D: Getting 'sci_echoback_cpu01' Demo Program to Work

Other Parts Discussed in Thread: LAUNCHXL-F28379D, C2000WARE

Hi, I'm working with a LAUNCHXL-F28379D C2000 Microcontroller for a group project and want to work with UART for interfacing between things like an RFID module and Bluetooth. We tried running the given 'sci_echoback_cpu01' example project to see how UART communication might work with our microcontroller, but we cannot get it to function properly at all.

The program is supposed to have the microcontroller communicate back and forth with a PC by sending text and echoing back user-entered text (using either Hyperterminal or a Putty terminal), but even after verifying the correct settings (bits per second, proper GPIO ports, etc.), the program will not execute properly. In our case, the code will always stop at this condition and never continue:

while(SciaRegs.SCIFFRX.bit.RXFFST == 0) { } // wait for empty state

The program is also supposed to output some text with the 'scia_msg()' function, but it never outputs anything to the terminal, even if it changes various register values. At best, we can get the microcontroller to send some junk characters to the terminal when connected to a PC, but this 'sci_echoback_cpu01' never works correctly at all.

I hope there is enough information for someone to help us (we are not that experienced with this microcontroller or UART in general, and prior forum posts about similar topics have not been that helpful), so any help is greatly appreciated, whether it's getting this function to work, or some other way we can easily experiment with UART and our Launchpad microcontroller. Thank you in advance for the replies.

  • Hi AM99,

    I apologize that this thread fell through the cracks and didn't get a prompt response.

    First thing is to confirm that your SW is coming from the most recent C2000ware version.

    Next, a good thing to check would be that your system is running at the desired clock rate. The best way to do this would be by enabling XCLKOUT:

    GpioCtrlRegs.GPCGMUX1.bit.GPIO73 = 0;
    GpioCtrlRegs.GPCMUX1.bit.GPIO73 = 3;
    GpioCtrlRegs.GPCDIR.bit.GPIO73 = 0;

    And then using a scope or frequency counter on GPIO73. Unfortunately, GPIO73 only comes to pin 37 on J9, which is very small (if you go this route you would want to solder a tiny wire to this pin that you can then connect a scope to). 200MHz SYSCLK should produce 25MHz on XCLKOUT.

    Alternately, you can use an ePWM timer to measure the clock frequency indirectly:

    EALLOW;
    GpioCtrlRegs.GPAMUX1.bit.GPIO4 = 1; // Configure GPIO4 as EPWM3A
    CpuSysRegs.PCLKCR2.bit.EPWM3 = 1; //ePWM clock enabled
    CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 0; //ePWM clock gated
    EPwm3Regs.TBCTL.bit.CTRMODE = 0; //ePWM up count
    EPwm3Regs.TBPRD = 249; //ePWM period = 250 ePWM Clocks
    EPwm3Regs.AQCTLA.bit.PRD = 3; //toggle GPIO4 on ePWM period match
    CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 1; //start ePWM clock
    EPwm3Regs.TBCTL.bit.FREE_SOFT = 3; //ePWM free run

    This should produce an exactly 100kHz square wave on GPIO4 (J2, Pin19) if the SYSCLK is 200MHz and the ePWM Clock is SYSCLK/2 and ePWM TBPRD HSPCLKDIV = /2 (which are the defaults).

    Now, as far as the SCI, I assume you are using the virtual COM port over the FTDI chip instead of sending SCI module inputs/outputs to pins and then to RS-232 transceivers?

    Whichever one you are using, you will want to scope the TX pin to ensure the baud rate is correct (and that the device is transmitting at all). If using the virtual COM port, TX uses GPIO42 (note, this requires a SW change from the stock example using GPIO28).

    When the program starts, it sends "Hello world"..., so this is when you want to be snooping on the TX pin.

    As to what is happening in the SW, the field RXFFST is the receive FIFO size. If it is zero, it means no characters have been received. Basically it is waiting for you to send something from the PC terminal to the device (which it then wants to echo back to you by re-transmitting it). Here again you might want to scope for activity on the SCI RX pin (GPIO43 if using the virtual COM port).
  • Hi AM99,

    Were you able to get this to work?