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.

SCI UART shows incorrect data after porting to FLASH programming 28377S

Other Parts Discussed in Thread: TMS320F28377S

Hi,

after having changed my launchpad to run on flash instead of ram, I found a new problem in the UART communication using SCI. I want to send over a test string character by character. This string being "abcdefghijk". However, when I set my receiving end to the same baud rate, I get a sequence of wrong characters. When just sending 1 character at a time, for example 'a' I still get wrong bytes at my receiving end.

When sending 1 string of "abcdefhijk" the receiving end gets "▒xx▒x▒x▒x<▒x▒x▒x▒x<▒▒x▒x▒".  This was received by using putty. (I also tried screen to record using a raspberry pi)

I have checked on the clock frequency and the divider of the baudrate. I want to get 1MBaud, with a clk of 200MHz this means that I should have a divider of 24. I also have tried a baudrate of 115200. Next to that I also tried if there was any difference on running the code from flash or ram, this didn't seem to make a difference at all.


I also tried to see what happens on a linux device which is recording. So I tried to find the baudrate of the signal accoring to a linux command "stty". This reported that there should be a baudrate of 9600. When I tried to record on this baud rate no date was to be found.

my setup:

- Launchpad XL TMS320F28377S

- connection via debug cable

- 200MHz clock

- 24 clock divider

part from main to init the sci

void initSCIA(void) {

	//configure GPIO
	//Pins - see launchpad schematic
	//84 - transmitter port - output
	//85 - receiver - input
	//Principle - see reference manual
	//Registers - see reference manual
	//Options - see specification manual
	 EALLOW;
	 //connection function
	 GpioCtrlRegs.GPCMUX2.bit.GPIO84 = 1;
	 GpioCtrlRegs.GPCMUX2.bit.GPIO85 = 1;
	 GpioCtrlRegs.GPCGMUX2.bit.GPIO84 = 1;
	 GpioCtrlRegs.GPCGMUX2.bit.GPIO85 = 1;
	 //async interface
	 GpioCtrlRegs.GPCQSEL2.bit.GPIO84 = 3;
	 EDIS;

	 //configure SCIA
	 //1 stop bit, no loopback, no parity, 8 bit char, idle-line protocol
	 SciaRegs.SCICCR.all = 0x0007;

	 //unit in software reset, disable RX ERR, SLEEP, TXWAKE, enable TX, RX
	 SciaRegs.SCICTL1.all = 0x0003;

	 SciaRegs.SCICTL2.bit.TXINTENA = 1;
	 SciaRegs.SCICTL2.bit.RXBKINTENA = 1;

	 //216 - 115200 baud - 1M152 bit/second, LSPCLK = 200MHz
	 //24 - 1000000 baud - 10M bit/second, LSPCLK = 200MHz
	 //divider = LSPCLK/(SCIBaudRate) - 1
	 SciaRegs.SCIHBAUD.all = 0x0000;
	 SciaRegs.SCILBAUD.all = 24; //216
	 //SciaRegs.SCILBAUD.all = 216;

   	 SciaRegs.SCICTL1.all = 0x0023;  // Relinquish SCI from Reset

}

Part from scio_io.c
int SCI_write(const char * buf, unsigned count)
{
    uint16_t writeCount = 0;
    uint16_t * bufPtr = (uint16_t *) buf;

    if(count == 0) {
        return (0);
    }

    while(writeCount < count){
        while(!SciaRegs.SCICTL2.bit.TXRDY);
        SciaRegs.SCITXBUF.all = *bufPtr;
        writeCount++;
        bufPtr++;
    }

    return (writeCount);

}
Part from main, used to call sci functions

	char returnString[20];
	char testReadValue = 0x61;
	int i;

	for(i = 0; i<10; i++){
		returnString[i] = i+testReadValue;
	}



while(1){ SCI_write(&returnString[0], 10); //reply with received byte DELAY_US(50000); }

  • Hi,

    1MB should be pretty tough to achieve for our devices. I am not positive if it is possible. But 115200 is possible.

    The SCI does not run off of SYSCLK. It runs off of the LSPCLK which by default is /4 from SYSCLK.

    Do your clock divider is way off right now. You need to calculate the HBAUD and LBAUD registers by using the LowSpeedPeripherClock frequency, not SYSCLK.

    Regards,
    sal
  • when changing the clock divider to 0 for LSPCLK I can reach up to 1MBaud and it now works with the divider of 24!
    thanks for your help!
  • I got the sending from the target working, however the receiving seems to be very difficult. I now use the function SCI_Read. Here the SCIRXST.bit.RXRDY never seems to be true. And at the moments it is true, it reads out 255 or 240 while I'm sending a character 'a', which is 97.

    I've tried both a raspberry pi and windows powershell to send over a character (or multiple characters). Both are set to the right baudrate (as I still can receive information). I've tested for both 115200 and 1M Baud rates

    Both the RX and TX lights on the launchpad are flashing.

    main:

    readCount = SCI_read(&readString[0], 1);


    sci_io.c:

    int SCI_read(char * buf, unsigned count)
    {
        uint16_t readCount = 0;
        uint16_t * bufPtr = (uint16_t *) buf;
    
        if(count == 0) {
            return (0);
        }
        while((readCount < count) && SciaRegs.SCIRXST.bit.RXRDY){
            *bufPtr = SciaRegs.SCIRXBUF.bit.SAR;//SCI_getData(ioSci);
            readCount++;
            bufPtr++;
        }
    
        return (readCount);
    
    }

  • Do you have the FIFO enabled? If you have the FIFO enabled you will need to poll from RXFFST.

    sal