TMS320F28335 SCI-A Initialization & Use

Jamie McPeek

Other Parts Discussed in Thread: TMS320F28335, CONTROLSUITE

We're looking to setup SCI-A on a TMS320F28335 eZdsp board as a transmit-only non-periodic messaging system for diagnostic and coverage data as pulling large amount of data over the debugger/USB connection is very slow (5-10 minutes for 20kb text file).

We've followed through the SCI Echoback example contained in the controlsuite and tried to set up the initial configuration to match that; however, the data transmitted out once it has been placed into the SCITXBUF is garbage/corrupted on the terminal screen.

The current initialization sequence is as follows:

InitializeSys()
{
   InitializePLL(0xA, 0x2);

   SysCtrlRegs.PCLKCR0.bit.SCIAENCLK = 1;

   InitializeInterrupts();
   InitializePieVectors();
   InitializeFlash();

   GpioCtrlRegs.GPADIR.bit.GPIO29 = 1;
   GpioCtrlRegs.GPAPUD.bit.GPIO29 = 0;
   GpioCtrlRegs.GPAMUX2.bit.BPIO29 = 1;

   InitializeADC();
   InitializeI2C();
   InitializeSPI();
   InitializeMcBSP();
   InitializePWM();
   InitializeTimers();

   SciaRegs.SCIFFTX.all = 0xE040;
   SciaRegs.SCIFFRX.all = 0x204F;
   SciaRegs.SCIFFCT.all = 0x0;

   SciaRegs.SCICCR.all = 0x7;
   SciaRegs.SCICTL1.all = 0x2;
   SciaRegs.SCICTL2.all = 0x1;

   SciaRegs.SCIHBAUD = 0x1;
   SciaRegs.SCILBAUD = 0x44;

   SciaRegs.SCICTL1.all = 0x22;
}

void scia_xmit(char a)
{
   while (SciaRegs.SCIFFTX.bit.TXFFST != 0) {}

   SciaRegs.SCITXBUF = a;
}

void scia_msg(char *msg)
{
   int i = 0;

   while (msg[i] != '\0')
   {
      scia_xmit(msg[i]);

      i++;
   }
}

int main(void)
{
   InitializeSys();

   scia_msg("Hello World!\r\n");
}

On the PC side, I have an instance of PuTTY running with 9600 baud, 8 data bits, 1 stop bit, no parity, no flow control.

The data I receive is garbled/corrupted and unreadable.

As part of the initialization, we are making use of external ram (ZONE7; ZONE6 is unused, so we could swap to that if necessary) - is it possible that is causing the issue?

We're using the default baud rate from the Echoback example (9600) for a 20 Mhz clock, which I believe is what we're setup as via the PLL. Trying to try other rates did not appear to make a difference. Attempting to use the BRR for a 37.5 Mhz clock didn't make a different either (just in case...).

Any assistance would be greatly appreciated.

over 11 years ago

0 Gautam Iyer over 11 years ago

Guru 192875 points

Hi Jamie,

According to your implementation, it does not feel like its the controlSuite example. I would like you to first try out the exact controlSuite example and comment on what you observe.

Regards,

Gautam

0 Jamie McPeek over 11 years ago in reply to Gautam Iyer

Prodigy 170 points

Gautam:

No, it's not the exact controlSUITE example - it was where we based it from to include it into our own application. The only intended change was not setting up the RX side since, in the actual application, we are not looking for input/incoming data.

When loading the example, data is able to be transmitted but data is not received - entering characters on the terminal do not result in an echoing of those characters. This was tried on two separate eZdsp boards and in both PuTTY and TeraTerm - input would not work.

The data is not garbage/corrupted; however, the SCIHBAUD and SCILBAUD or uninitialized. The example checks for CPU_FREQ_150MHZ and CPU_FREQ_100MHZ, both of which are undefined.

We tried not initializing the SCI{H,L}BAUD values at initialization in the example above, but that did not resolve the garbled output.

0 Gautam Iyer over 11 years ago in reply to Jamie McPeek

Guru 192875 points

When loading the example, data is able to be transmitted but data is not received - entering characters on the terminal do not result in an echoing of those characters. This was tried on two separate eZdsp boards and in both PuTTY and TeraTerm - input would not work.

Did you check the baudrate on DSO? Is it correct?

Regards,

Gautam

0 Jamie McPeek over 11 years ago in reply to Gautam Iyer

Prodigy 170 points

Gautum:

Using the ControlSUITE example (set to 9600 baud via 0x1E7), driving an infinite loop of output 0x5, resulting in a frequency of around 3 to 4 kHz.

I adjusted the BRR to 0x28 to represent a 115,200 baud, still driving an infinite loop of output 0x5, resulting in a frequency of around 34 to 35 kHz.

One note about the ControlSUITE example: the CPU_FRQ_150MHZ is defined (counter to what was stated above); however, the Index needed to be rebuilt to show appropriate code folding/hiding.

Back to the specific application, I attempted to change the SCI{H,L}BAUD values in the code to 0x28 and checked the frequency - in this case, it was around 68 to 69 kHz.

I changed the BRR up from 40 to 80, re-executed, and noted a frequency of around 34 to 35 kHz. I changed the code back to actually transmit a message ["Hello World!\r\n"], executed, and observed the data being appropriately transmitted to the terminal window.

Working backwards, this would represent an LSPCLK of around 75 MHz, which is in line with other discoveries from today:

On the eZdsp, the OSCCLK is coming in at 30 MHz. I observed this with an oscilloscope on the U11 output on the back of the board.

Providing a DIV of 0xA and a DIVSEL of 0x2 should have the board running at 150 MHz. We have a control loop interrupt on CPU Timer 0 set to trigger every 2500 cycles (originally designed as 40 kHz on a 100 MHz processor).

By putting a GPIO toggle into that code, I was able to see that it executes at a 30 kHz frequency, which would point back to an overall clock rate of 75 MHz.

In addition to the PLL being set with 0xA and 0x2, the HISPCP, LOSPCP, XTIMCLK, and CLKMODE are set as follows:

SysCtrlRegs.HISPCP.all = 0x2;
SysCtrlRegs.LOSPCP.all = 0x1;

XintfRegs.XINTCNF2.bit.XTIMCLK = 0;
XintfRegs.XINTCNF2.bit.CLKMODE = 0;

XintfRegs.XINTCNF2.bit.CLKOFF = 0;

With those settings, I would expect to see the XCLKOUT from the board be equal to the SYSCLKOUT; however, when measured with the oscilloscope (TP2) I only receive what appears to be incorrect data in the range of 400 Hz to 9 kHz (sometimes spiking as high as 400 kHz).

This was measured on two separate boards and both behaved similarly.

So in summary, I am now able to transmit data from the board with serial as 115,200 baud, but I am no closer to understanding why the settings do not align with the expectations.

Any assistance in understanding why we're running at 75 MHz instead of 150 MHz would be greatly appreciated.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28335 SCI-A Initialization & Use