Problem with serial

Kernel
1

Hi to all!
I’m a newbe to FreeRTOS and I have a problem with my first example. I’m using FreeRTOS on ATmega2560.
I tryng to run a simple program that receive a char from the serial and send the same char back.
I have done a program for do this, but when i connect the serial terminal, i receive some values of 0xf0 even if I write nothing. The values of 0xf0 depend of the size of the queues that i using in my program. I use two queues of the same size, one for the rx side and one for the tx side of the serial.

This is my main task, in this task I reading the rx queue and if there is an item, i put this item into the tx queue and after i start the tx interrupt:

`static void vTestSerial( void *pvParameters ){
    /* The parameters are not used. */
    ( void ) pvParameters;

    uint8_t tmp;

    /* Cycle for ever, delaying then checking all the other tasks are still
    operating without error. */
    for( ;; )
    {
	
	    /* Wait for the maximum period for data to become available on the queue.
	    The period will be indefinite if INCLUDE_vTaskSuspend is set to 1 in
	    FreeRTOSConfig.h. */
	    if( xQueueReceive( xRxedChars, &tmp, 0 ) != pdPASS )
	    {
		    /* Nothing was received from the queue – even after blocking to wait
		    for data to arrive. */
	    }
	    else
	    {
		    /* tmp now contains the received data. */
		
		    /* Send the message to the queue, waiting for 10 ticks for space to become
		    available if the queue is already full. */
		    if( xQueueSend( xCharsForTx, &tmp, 0 ) != pdPASS )
		    {
			    /* Data could not be sent to the queue even after waiting 10 ticks. */
		    }
		    else{
			    START_SERIAL_TX;
		    }
	    }
    }
}

`

and this are the interrupt routines:

SIGNAL( USART0_RX_vect ){
    uint8_t cChar;
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    /* Get the character and post it on the queue of Rxed characters.
    If the post causes a task to wake force a context switch as the woken task
    may have a higher priority than the task we have interrupted. */
    cChar = GET_CHAR;

    xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken );

    if( xHigherPriorityTaskWoken != pdFALSE )
    {
	    taskYIELD();
    }
}
/*-----------------------------------------------------------*/

SIGNAL( USART0_UDRE_vect ){
    uint8_t cChar;
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    if( xQueueReceiveFromISR( xCharsForTx, &cChar, &xHigherPriorityTaskWoken ) == pdTRUE ){
	    /* Send the next character queued for Tx. */
	    PUT_CHAR( cChar );
    }
    else
    {
	    /* Queue empty, nothing to send. */
	    STOP_SERIAL_TX;
    }
}

I have adapted this code from the demo in the AVR328 folder.

Can anyone tell me where am I wrong?

2

First thing to note is those demos were written long before there were stream buffers, and a stream buffer would be much more efficient than a queue to do this.

tmp is uninitialised the first time through your loop, so you are sending (and then receiving if you have a loopback connector) whatever value happened to be in the variable on start up.

Other than that - are you certain the serial port and interrupt handlers are set up correctly if you changed the target hardware. I would suggest starting with a simple UART Tx example without FreeRTOS, just from main, to make sure the UART is working as you expect.

3

Hi Richard, many thanks for the reply!
I’m sorry, but yesterday I missed some important info about my problem.
I have two queues of five elements (uint8_t), so I receive a five 0xf0 only when I connect my serial terminal for the first time. If I disconnect the serial terminal and I reconnect it again, I receive seven 0xf0 even if I send nothing.
However if my serial terminal is connected and I send a number , for example the number 5, i receive the correct value that is 5. This appens if I use the terminal extention for the Atmel Studio 7. If i use the Bray terminal, this behavior is different. When I connect the serial terminal I receive two 0xf0, the same appens if I disconnect and riconnet the terminal. However even if I use the Bray terminal, when after I connected the serial terminal, if I send a number I receive the same number.
So, I think that the setup of the UART is done correctly, because I send and receive the same number, that is what I expect from my example.

I don’t know if this is a problem of FreeRTOS or if is a problem of my SO. I have done this experiments on Windows 10 home edition for 64 bit. Now i try to do the same thing on another pc that run Windows 7 at 32 bit.
In any case, can you tell me if the FreeRTOS part is done correctly? Stream buffer apart, my setup, FreeRTOS task and UART interrupts, are done correctly?
Another thing about FreeRTOS, i have download the last version (10.3.1) and i have modified the port module for the Atmega 2560. I modified this line:

#define portCOMPARE_MATCH_A_INTERRUPT_ENABLE	( ( uint8_t ) 0x20 )

in the original port module, the value it was 0x10.
I have added this code in the pxPortInitialiseStack method:

usAddress >>= 8;
*pxTopOfStack = ( usAddress & 0x00ff );
pxTopOfStack--;

modified the prvSetupTimerInterrupt method in this way:

ucLowByte = TIMSK1;
ucLowByte |= portCOMPARE_MATCH_A_INTERRUPT_ENABLE;
TIMSK1 = ucLowByte;

and finally i have modified the interrupts signature for the preemptive support:

void TIMER1_COMPA_vect( void ) __attribute__ ( ( signal, naked ) );
void TIMER1_COMPA_vect( void )

and

void TIMER1_COMPA_vect( void ) __attribute__ ( ( signal ) );
void TIMER1_COMPA_vect( void )

Are these setting correct, or i miss some thing?

4

The process of connecting a terminal to a serial line often causes a burst of line noise, which can be received as a number of different things. It is likely that your GET_CHAR (what every that macro expands to) is returning F0 in the case of a receive error character. You may want to look at the documentation for those routines and see if there is a way to test for error conditions and perhaps not queue up characters received with an error.

5

Hi Richard, thank for the reply!
I have write the GET_CHAR macro for convenience, and it’s very simple, as you can see:

#define GET_CHAR ( UDR0 )

However, i think that you are very near at the solution of the problem.
I have done some test, and the good news is that my first FreeRTOS application work correctly! :smiley:
I have tested it using a baudrate of 9600, and I not see any problem with the serial terminal.
The bad news is that if i use different baudrate, when I wrote this post I used a baudrate of 115200 but I also tryed with a baud rate of 38400, the problem arise.
Specifically if I use a baudrate of 115200 I read some values of 0xf0, if I use a baudrate of 38400 the values are different like 0xfe and 0xff.
I’m sure that the UART setting are correct because I have alway used them in my projects.
I think that the problem is the hardware, in particular the oscillator that is on the (clone of) Arduino Mega shield.
At this moment I haven’t a possibility to check the rx and tx serial signals on the shield. However I have other shield but for Arm processor, now I use these shields to learn FreeRTOS.

In any case, thank you all for the help!

6

So your code is NOT checking the serial port status register, so you don’t know if the interrupt was for a successfully received character or for a serial reception error. Generally, ISRs will start with a check on a status register to see what interrupt from that device are pending, and process those. You then need to decide what to do for a receive error. The connection to the serial line will often cause a momentary blip on the serial data line, higher baud rates are more apt to see that blip as a character than the slower ones. At 115200 the whole character is shorter than one bit time of 9600, so 9600 might not see the blip as a valid start bit.

7

You are right Richard, I should check the serial status register when I receive a char. This is a good programming practice. I don’t do this because I haven’t any output to see the result of the status register. I can use a led to see the if there an error, now i try to add this check to my code.

However this is my first time that I observe this behaviour on the serial. I think that is the oscillator that don’t work properly, but i’m not sure about this because I can’t do any measurements…
On the other hand I’m sure that the UART setup is correct because in the past I have used it many times without any problem on the same Arduino Mega shield.

This is my first experience with FreeRTOS, and I already understand that is difficult to follow and debug the code, so i need some tricks to check these and other future errors and the serial is a good debug instrument.

8

Normally, the Serial Ports are running of a divider of the CPU clock, and if that is going bad, you will have all sorts of problems.

It could be the the Serial receiver chip is more sensitive to that line noise than you have seen previously, or even that previously you had code that just threw away characters with receive errors. This is clearly not a FreeRTOS issue, maybe only vaguely connected because you wrote your own less robust serial driver.

9

Hi Richard!
Of course this isn’t a FreeRTOS problem. I had wrote this post because I was not sure about the FreeRTOS code. Now i realized that the problem isn’t the FreeRTOS code.

I know this, now I changed my hardware to learn FreeRTOS. I have a couple of boards that use an Arm Cortex M microcontroller, I will use these to learn FreeRTOS. I had started with the Atmega2560 because this microcontroller is relatively simple to program respect to the Arm Cortex M.
However I will try to investigate if there is some components of the Atmega2560 board that is broken.