UART behaves different out of DEBUG mode

Hello Cenek,

You mean if you don't use CCS, you still can receive data but the data is wrong, right?

Have you ever tried to connect the UART port (ground pin) together with your PC's ground?

Regards,

Jo

Cenek Albl said:

Is there a specific thing the Debugger does to the behavior of UART0 on Stellaris which would explain this behavior?

I am not aware of anything the debugger does to affect the behaviour of UART0.

However, UART0 is connected to the PC via a Virtual COM Port. As noted in this thread I am supicious of the Virtual COM Port as have had problems with it.

If there is a bug in the Stellaris In-Circuit Debug Interface (ICDI) part of the Stellaris Launch Pad, which handles the debugging and Virtual COM Port, then that is maybe why attaching the debugger makes a difference.

Can you try connecting a TTL to RS232C converted to a different UART on the Stellaris and see if that makes a difference?

Yes Jo exactly.

I have it connected through the Debug micro-USB port on the Launchpad. I supposed the grounds should this way be common and also the HW connection is the same for both cases (Debug-works,NODEBUG-doesn't work). 

***EDIT***

I can now confirm that it is not a HW fault of UART, when I loop the numbers right back I get the same values I sent from the PC. So it is somewhere in saving the received chars in the array and reading them out.

So my question should probably be - is there a difference in code exectution between having the Debugger on and pressed "play" button and not have the Debugger on? I think that the code is the same, since I onlly use the Debugger to upload the code.

This is my UART handler:

void
UART0IntHandler(void)
{
 unsigned long ulStatus;
 //one byte for command type, 4 bytes for value

 //
 // Get the interrrupt status.
 //
 ulStatus = UARTIntStatus(UART0_BASE, true);

//
 // Clear the asserted interrupts.
 //
 UARTIntClear(UART0_BASE, ulStatus);

//
 // Loop while there are characters in the receive FIFO
 //
 while(ROM_UARTCharsAvail(UART0_BASE))
 {
 command[buff_id] = UARTCharGetNonBlocking(UART0_BASE);
 buff_id++;
 // Delay for 0,1 millisecond. Each SysCtlDelay is about 3 clocks.
 SysCtlDelay(SysCtlClockGet() / (10000 * 3));

}
}

And this is my processing routine called when buff_id>=5 :

process_command(){
 double sample_time_in_sec = 1.0/((double)sample_rate);
 //handle different types of commands
 switch(command[0]){
 // change outer loop P
 case 0:
 kp2=*(float *)(command+1);
 break;
 // change outer loop I
 case 1:
 ki2=(*(float *)(command+1))*sample_time_in_sec;
 break;
 // change outer loop D
 case 2:
 kd2=(*(float *)(command+1))/sample_time_in_sec;
 break;
 }
 buff_id-=5;

}

***EDIT***

If I loop the contents of command[] back as they are received after

command[buff_id] = UARTCharGetNonBlocking(UART0_BASE);

Then I get correct values.

When I send the contents of command[] in the function 

process_command()

Then its wrong.

Again, with the Debugger running, it is correct on both places, therefore it is kind of hard for me to debug this:)

OK I found the reaason for this issue.

It was actually quite simple and probably obvious to someone more experienced than me.

The Launchpad, when powered up, somehow places 1 byte in the UART in buffer. Where it exactly comes from I don't know, it could be also because it is connected to my PC.

This caused the byte to be read into command[] array and shift my buffer_id variable by one byte and therefore mess up every consequent readout.

It did not happen using the Debugger simply because the Launchpad was always powered up before the Debugger was run and running the Debugger cleared the in buffer of the UART.

The soultion to this was simple, just to add a buffer clearing procedure after the startup:

while(ROM_UARTCharsAvail(UART0_BASE))
 {
 unsigned char dummy = UARTCharGetNonBlocking(UART0_BASE);
 }

Thanks for the replies everyone anyway!

Cenek

Cenek Albl said:

The Launchpad, when powered up, somehow places 1 byte in the UART in buffer. Where it exactly comes from I don't know, it could be also because it is connected to my PC.

I created this test program to investigate:

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include "inc/hw_memmap.h"
#include "driverlib/debug.h"
#include "driverlib/gpio.h"
#include "driverlib/rom.h"
#include "driverlib/sysctl.h"
#include "driverlib/pin_map.h"
#include "driverlib/uart.h"
#include "driverlib/rom_map.h"

int
main(void)
{
 uint32_t rx_data;
 char diag_text[64];
 char *diag_char;
    //
    // Set the clocking for a 80MHz system clock
    //
    MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ |
                       SYSCTL_OSC_MAIN);

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    MAP_UARTClockSourceSet (UART0_BASE, UART_CLOCK_SYSTEM);
    MAP_UARTConfigSetExpClk (UART0_BASE, MAP_SysCtlClockGet(), 115200,
                       UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE);
    MAP_GPIOPinConfigure (GPIO_PA0_U0RX);
    MAP_GPIOPinConfigure (GPIO_PA1_U0TX);
    MAP_GPIOPinTypeUART (GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    MAP_UARTFIFOEnable (UART0_BASE);
    MAP_UARTEnable (UART0_BASE);

    rx_data = MAP_UARTCharGet (UART0_BASE);
    sprintf (diag_text, "Initial UART data=0x%X\n\r", rx_data);

    for (;;)
    {
     for (diag_char = diag_text; *diag_char; diag_char++)
     {
      MAP_UARTCharPut (UART0_BASE, *diag_char);
     }

     MAP_SysCtlDelay (MAP_SysCtlClockGet());
    }
}

It just reads the first character from UART0, then every 3 seconds outputs a debug string to UART0 containing the hex of the first character read. The repeated output allows the initial character to be seen following the the delay in being able to connect HyperTerminal on the PC after powering up the launch pad.

When download from the debugger and set running, no output appears until after send one character from HyperTerminal, where the output contains the hex value of the character sent from the PC.

When I powered-up the Stellaris launchpad with this program in flash, and then connected HyperTerminal the following was being output:

Initial UART data=0x500

The TivaWare driverlib documentation doesn't make it clear, but the value returned from UARTCharGet is the value from the UART Data (UARTDR) register which has:

- UART Overrun Error in bit 11

- UART Break Error in bit 10

- UART Parity Error in bit 9

- UART Framing Error in bit 8

- Received data in bits 7 .. 0

The initial value of 0x500 means character data of 0x00 with a UART Break Error and a UART Framing Error. This could be explained by upon power-up if the program running in the target Stellaris device initialises its UART0 and starts trying to receive before the Virtual Serial Port in the Stellaris In-Circuit Debug Interface (ICDI) has initialised its UART output. During this interval the UART0 Rx on the target Stellaris could be "low" which means a break condition.

Cenek Albl said:

This caused the byte to be read into command[] array and shift my buffer_id variable by one byte and therefore mess up every consequent readout.

You might want to improve the error detection / recovery in the serial protocol. Look in the SiRF Binary Protocol Reference Manual section on the Protocol Layers for an example for a protocol which can validate received messages, and thus synchronise to the start of the next valid message after an error.