Really strange thing when using xQueueReceive() in FreeRTOS 7.30

gussabina wrote on Wednesday, 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;

uint32_t test = 0;
.................
			while(1) {
				test = 1;
				if (xQueueReceive(queue_handle, &item, 100)) {
					printf("RadioProcess got item %d from queue\r\n", item);
					printf("test %d\r\n", 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

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

gussabina wrote on Wednesday, 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

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

gussabina wrote on Thursday, 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 sys_arch_sem_wait( ) function in the lwIP ethernet task;

static void gmac_task(void *pvParameters)
{
	struct gmac_device *ps_gmac_dev = 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

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