Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on April 22, 2016

I am currently developing a project that transfers and sends wireless data to another device. I have had no problem implementing a task to transfer the data over wirelessly. However, I've had incredible difficulty being able to successfully receive wireless data on my system.

The XBEEs are on the USART0 line of the Arduino Due. I have another sensor that I read from every 1000 ms using freertosusartserialreadpacket without any issues whatsoever across USART1. The wireless receive task does grab data from the USART0 line, however there are a lot of issues with the buffer that they are read into.

The data that is copied into my buffer never begins filling in from the beginning, instead I will have nulls in the beginning of my buffer, followed by some data then more nulls and so on until the end of the buffer. I know roughly the size of the data I am trying to read, whether it is exact or slightly larger than what I'm expecting this issue occurs. I have verified that the nulls are not coming from the transfer end by verifying its transmission by hooking up an XBEE to a USB dongle and seeing the data being transferred without problems. I also cleared the buffer with 0x44(char 'D') instead of nulls to verify this, instead of a mixture of nulls and data it is now a mixture of the 0x44 char and data.

If I try to read significantly more than what I expect, the behavior becomes more chaotic. I have verified this task has the highest priority in the entire project as well as it executing at its given time interval. I have attempted increasing the value of the timeoutdefinition from (100UL / portTICKRATEMS) all the way to (1000UL / portTICKRATEMS) in case the function was exiting the peripheral before it could complete the grabbing of data from the PDC. The more I increased time, the worse the data became as it was starting to become jumbled together out of order.

I am at a complete loss since I am able to read successfully in my other task that runs at every 1000 ms while this one runs at 16 ms. I have increased the speed to account for the disparity between the two up until 500 ms, however, this does not change the behavior occuring in my wireless receive task. Any help or advice would be greatly appreciated!

XBEE freertos_usart_serial_read_packet Issues

Posted by rtel on April 23, 2016

Which version of FreeRTOS are you using? The reason for asking being that it might be necessary to change a mutex used in the driver to a binary semaphore - depending on the version.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on April 24, 2016

This is the version that I am using based off what I grabbed from FreeRTOS.h

FreeRTOS V7.3.0 - Copyright (C) 2012 Real Time Engineers Ltd.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on April 25, 2016

Just as a note, all the semaphores that I use to resume tasks are already Binary semaphores, the only non Binary semaphore I am using is for the freertosusartwritepacketasync() function call. I changed the XBEE_RX semaphore from binary to a mutex one, but it didn't fix the issue I am having.

An interesting note I would like to add is that I am able to send packets 1 at a time no problem from XCTU, but when I have it send the same packet in an infinite loop that is at the same rate as my TX task, the same problem occurs where the data is jumbled up between whatever character I use to clear the buffer.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on April 29, 2016

I've switched to sending and receiving XBEE API Packets now, I have no issues with the transfer task, however I am still having the exact same problems on the receive end.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 5, 2016

Today I attempted upgrade from my version, 7.3 to that of v8.2.3 I followed the directions in the folder on how to install the files, I was able to compile with no errors while leaving the backwards compatible calls in the code still. Nothing would work as I thought, so I switched everything over to the new format(xTaskHandle to TaskHandle_t etc).

After converting everything and making sure there were no more old format variables, the project still did not work at all. When attempting to debug I started hanging up when stepping through vTaskStartScheduler(). Unfortunately I did not see which line caused the hang up to occur, I tried restarting Atmel Studio to debug once more. Now I am unable to debug at all, I keep receiving an error code stating it can't connect to my debugger.

Would anyone have any advice as to why the scheduler would start hanging up when I've upgraded from v7.3 to v8.2.3?

XBEE freertos_usart_serial_read_packet Issues

Posted by davedoors on May 5, 2016

newer versions have more asserts, maybe you are in a failed assert.

XBEE freertos_usart_serial_read_packet Issues

Posted by heinbali01 on May 5, 2016

That is possible, that you've hit a new configASSERT()

You might have found these two texts about upgrading:

http://www.freertos.org/upgrading-to-FreeRTOS-V8.html http://www.FreeRTOS.org/History.txt

I keep receiving an error code stating it can't connect to my debugger

It isn't clear to me which Atmel board you are using. Some boards (like SAM4E) have a jumper that can be set to cause a hard erase of the chip. That can be used when you've really got stuck.

Today I attempted upgrade from my version, 7.3 to that of v8.2.3

Are you sure that all 7.3 header files have become invisible now? Including a wrong header file will be fatal.

Have you switched on all compiler warnings? If not, I would do so. Something like :

~~~~ -Wall -Wextra -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-sign -Wsign-compare -Wstrict-overflow -Woverflow -Wtraditional-conversion ~~~~


XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 5, 2016

I will try those flags once I get a chance today, I did not have all of those included when I compiled the first few times. The board I am using is the sam3x, I'm going to clear the log file and uninstall Atmel Studio along with my drivers, this has fixed the issue in the past whenever I've had problems connecting to the debugger. Once I have it up I will reply again at which line the hang up occurs.

As for the header files, I made sure to delete all the old ones when I included the v8.2.3 header files. I did delete FreeRTOS+CLI.c and .h from my directories because v8.2.3 did not have these files, however, based off how I understand the comman line interface, it should not affect the schedulerer starting up.

In the RTOS Viewer I was able to determine that all tasks and their priorities are being set correctly in the beginning. All my priorities and timers have the same values as in v7.3, and since they are created successfully in the beginning I do not think these settings are causing the hang up in the scheduler.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 5, 2016

I will double check this, but I did not receive an assert error for the checks that I had setup.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 5, 2016

Okay I have way more warnings popping up now, most them being; "Warning passing argument 3 of 'xTaskGenericCreate' with different width due to prototype [-Wtraditional-conversion] | file: task.h line: 345"

The line is: #define xTaskCreate( pvTaskCode, pcName, usStackDepth, pvParameters, uxPriority, pxCreatedTask ) xTaskGenericCreate( ( pvTaskCode ), ( pcName ), ( usStackDepth ), ( pvParameters ), ( uxPriority ), ( pxCreatedTask ), ( NULL ), ( NULL ) )

Sorry for the above line, no matter what text editor I would copy it from it kept making the text so huge......

This was another warning I was receiving quite a bit of as well. "Warning passing argument 5 of 'piosetoutput' as unsigned due to prototype [-Wtraditional-conversion] | file pio.c line 381"

The line is: piosetoutput(ppio, ulmask, (ultype == PIOOUTPUT1), (ulattribute & PIOOPENDRAIN) ? 1 : 0, (ulattribute & PIO_PULLUP) ? 1 : 0);

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 6, 2016

Okay I have determined the hangup occurs in the xTaskResumeAll function while the scheduler is setting up. Unfortunately the debugger crashed and is giving me problems again and I was not able to determine which line the Program Counter is pointing to when this hangup occurs.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 6, 2016

After messing with the debgger this morning, I was able to get it back up and running. Weirdly enough I stepped through xTaskResumeAll 4 times without any hanging up or crashing. As I continued to step through the program, it hit the following function and was stuck in this infinite loop.

In exceptions.c void Dummy_Handler(void) { while (1) { } }

This caught me by surprise since I do not enable any interrupts of my own, the only interrupts that are enabled are handled by FreeRTOS and Atmel's FreeRTOS_Usart driver.

I started running the debugger again in order to verify what line the program counter was at last in order to try to find out which interrupt is causing the Dummy_Handler to be called.

Now my debugger is crashing at random times, this time it crashed at line 160 for heap_4.c:

if(pxEnd == NULL)

I'm fairly certain my issue is an interrupt being initialized incorrectly(Dummy_Handler) and the debugger is crashing randomly when I step through it, not those lines of code actually causing a hang up. I've had issues before with Atmel Studio and debugging on different boards and different debugging hardware devices.

XBEE freertos_usart_serial_read_packet Issues

Posted by rtel on May 6, 2016

Did you change the start-up code at all? By which I mean the code that runs before main() is called?

Information on determining which interrupt is executing can be found on the following page: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

You may just be able to view and decode the register in the debugger, rather than copying it into a register as per the code snippet on the above linked page.

XBEE freertos_usart_serial_read_packet Issues

Posted by gstenos on May 6, 2016

Thank you so much, I'm going to look into that right now.

XBEE freertos_usart_serial_read_packet Issues

Posted by peervincent on June 4, 2018

Hello George, I am not sure if the incorrectly(DummyHandler) has something to do with the actual error of having your zeros in front of the received data. I just got same issue. Using Arduino Due and the freeRTOS USART (freertosusart_serial.x) receive function just brings up the same. Normally - data reception works but in some cases preceding 0x00's are received screwing up my succeeding parser stuff. And when you have a closer look on it, the data is not overwritten, it's shifted by these 0x00 bytes! So my question is, how did you solve it? By updating the FreeRTOS files? What about the appropriate ASF Files at ....srcASFcommonservicesfreertossam ? Regards, Peer

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner