Quality RTOS & Embedded Software

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




Loading

Really strange thing when using xQueueReceive() in FreeRTOS 7.30

Posted by gussabina on September 20, 2017

Hello: I'm using FreeRTOS 7.30 and I'm seeing** a really strange thing** when using xQueueReceive. Basically it's like once I get an item from the queue, a variable (which is not related to xQueueReceive at all) changes its value. This is the code;

~~~ uint32t test = 0; ................. while(1) { test = 1; if (xQueueReceive(queuehandle, &item, 100)) { printf("RadioProcess got item %d from queuern", item); printf("test %drn", test); //process item }
} ~~~

And this is the console when an item is received;

RadioProcess got item 2 from queue test 0

For some reason, the value of test is cleared after xQueueReceive()... There is not other part in the code using test variable at all.... It's only set to 1 everytime the while loop starts...

What could be the issue here? Thanks in advance Gus


Really strange thing when using xQueueReceive() in FreeRTOS 7.30

Posted by rtel on September 20, 2017

Are you 100% sure the variable is changing its value and just not being printed out incorrectly? Have a look at the variable's value in the debugger to be sure.

If the variable is genuinely being clobbered then view the variable in the debugger's watch window and step through the xQueueReceive() function until you see it change. I suspect your linker script is wrong, stacks are overflowing, you have run out of heap but not noticed (do you check the return value of all 'create' functions), or some other similar issue that is meaning you have more than one thing at the same memory location (or other similar corruption).

You are using a really old version of FreeRTOS. If you were using a later version then you could use things like malloc failed hooks and a wealth of additional configASSERT() entries that would help track the problem. http://www.freertos.org/FAQHelp.html


Really strange thing when using xQueueReceive() in FreeRTOS 7.30

Posted by gussabina on September 20, 2017

Hello: Thanks for the input. Yes, I think I have a memory corruption problem at some point. I will try to update FreeRTOS but I have many other stuff integrated and it's a pain every time I update something...

Meanwhile, how can I check if the stack is overflowing or the heap is running out of space? I would appreciate any help on this.

Thanks Gus


Really strange thing when using xQueueReceive() in FreeRTOS 7.30

Posted by rtel on September 20, 2017

Yes, I think I have a memory corruption problem at some point. I will try to update FreeRTOS but I have many other stuff integrated and it's a pain every time I update something...

Unless you have edited the FreeRTOS source code I believe it should be a drop in replacement.

Meanwhile, how can I check if the stack is overflowing or the heap is running out of space? I would appreciate any help on this.

As I recall I already did that in my last post - click the link I posted.


Really strange thing when using xQueueReceive() in FreeRTOS 7.30

Posted by gussabina on September 21, 2017

Hello: I increased stack and heap but didn't help. I further debugged the issue, and it seems the variable is cleared after the sysarchsem_wait( ) function in the lwIP ethernet task;

~~~ static void gmactask(void *pvParameters) { struct gmacdevice *psgmacdev = pvParameters;

while (1) {
	/* Wait for the RX notification semaphore. */
	sys_arch_sem_wait(&ps_gmac_dev->rx_sem, 0);

	/* Process the incoming packet. */
	ethernetif_input(ps_gmac_dev->netif);

}

} ~~~

This function waits for the semaphore from the Ethernet ISR for each packet to proceed with the packet process. For some reason, when this happens, the variable (which is totally unrelated with this) is cleared...

Any thoughts? Thanks Gus


Really strange thing when using xQueueReceive() in FreeRTOS 7.30

Posted by rtel on September 21, 2017

Right. This is one of the threads that started by omitting the information that lwIP (or some other complex software) was being used to. I would recommend starting by examining the lwIP integration - from experience 90% of this type of thread ends with finding an error there.


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

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