XBEE freertos_usart_serial_read_packet Issues

gstenos wrote on Friday, 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 freertos_usart_serial_read_packet 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 time_out_definition from (100UL / portTICK_RATE_MS) all the way to (1000UL / portTICK_RATE_MS) 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!

rtel wrote on Saturday, 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.

gstenos wrote on Sunday, April 24, 2016:

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

FreeRTOS V7.3.0 - Copyright © 2012 Real Time Engineers Ltd.

gstenos wrote on Monday, 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 freertos_usart_write_packet_async() 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.

gstenos wrote on Friday, 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.

gstenos wrote on Thursday, May 05, 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?

davedoors wrote on Thursday, May 05, 2016:

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

heinbali01 wrote on Thursday, May 05, 2016:

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

You might have found these two texts about upgrading:


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


gstenos wrote on Thursday, May 05, 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.

gstenos wrote on Thursday, May 05, 2016:

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

gstenos wrote on Thursday, May 05, 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 ‘pio_set_output’ as unsigned due to prototype [-Wtraditional-conversion] | file pio.c line 381”

The line is:
pio_set_output(p_pio, ul_mask, (ul_type == PIO_OUTPUT_1),
(ul_attribute & PIO_OPENDRAIN) ? 1 : 0,
(ul_attribute & PIO_PULLUP) ? 1 : 0);

gstenos wrote on Friday, May 06, 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.

gstenos wrote on Friday, May 06, 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.

rtel wrote on Friday, May 06, 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:

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.

gstenos wrote on Friday, May 06, 2016:

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

peervincent wrote on Monday, June 04, 2018:

Hello George,
I am not sure if the incorrectly(Dummy_Handler) 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 (freertos_usart_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 …\src\ASF\common\services\freertos\sam ?
Regards, Peer