I get stuck in vListInsert. How can this line work if both xItemValue and xValueOfInsertion == same value (7 in my case)? Note that the list is empty at the time of the call.

    for( pxIterator = ( ListItem_t * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext ) /*lint !e826 !e740 The mini list structure is used as the list end to save RAM.  This is checked and valid. */

I suppose the shown code comes fromlist.c line 192 : ~~~~ for( pxIterator = ( ListItem_t * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext ) /* lint !e826 !e740 The mini list structure is used * as the list end to save RAM. This is checked and valid. */ ~~~~ Who is calling vListInsert() in your case? Is it called from within the kernel, or are you using it to maintain a sorted list?

I get stuck in vListInsert

In which case you probably have a data corruption – the most common cause of which is an invalid interrupt priority. Did you read the comment above that line, which provides hints as to how to find this (defining configASSERT(), ensuring stack overflow checking is on, etc.)?

vListInsert does not do what the comments say

Which comment are you referring to?

To run this down I need to understand some things: – The basic problem is that xItemValue and xValueOfInsertion == same value so vListInsert can’t get out of the loop. So it must be true that xItemValue is unique which would allow vListInsert to exit the loop. – vListInsert is being called from vTaskPlaceOnEventList (line 2820 of tasks.c) which is called from xQueueGenericReceive(). So my question is, can someone explain that area of the logic?

The basic problem is that xItemValue and xValueOfInsertion == same value

What are you calling xItemValue? Are you referring to pxIterator->pxNext->xItemValue?

so vListInsert can’t get out of the loop

pxIterator->pxNext->xItemValue changes on each iteration of the loop, and the last value it will hold is 0xffffffff, in which case the loop will exit as the loop will never be entered if xValueOfInsertion is also 0xffffffff. At this point I have to refer you back to my previous post, which you have not replied to: “In which case you probably have a data corruption – the most common cause of which is an invalid interrupt priority. Did you read the comment above that line, which provides hints as to how to find this (defining configASSERT(), ensuring stack overflow checking is on, etc.)?”

I ran into this problem once, too, the reason was the reverse logic of interrupt priorities and priority values on Cortex-M architectures (I thought my interrupts were running at the lowest priority level with priority value 0, but they were not… setting the level to 255 fixed everything). I was getting bus faults all the time in the pending software request handler right after the call to vTaskSwitchContext() when the handler tried to load the value of SP from an invalid address that came from an invalid pxCurrentTCB value that in turn was corrupted during vTaskSwitchContext() by the interrupt, probably during the listGETOWNEROFNEXTENTRY() macro in taskSELECTHIGHESTPRIORITY_TASK().

Real Time Engineers Ltd: As I said, this is in vListInsert. You will see xItemValue there. Yes, you spotted it. Yes it changes on each itteration of the loop but note that I said the list is empty so all of the pNext’s will point to the same structure which means it will not actually change. The list does not hold 0xffffffff … maybe it should but it doesn’t. I have searched for a data corruption. Today I found that the number of items in the list (forgot the name of that element) is 2 but the list is empty. So I think this may be due to a race condition which I have not run down. This is not my code so it is very difficult to run down without understanding the logic in FreeRTOS. The call stack shows: xSemaphoreTake() (which is macro’d to xQueueGenericReceive) vTaskPlaceOnEventList( &( pxQueue->xTasksWaitingToReceive ), xTicksToWait ); vListInsert() So I think this has to do with task switching. So I asked the question … can someone please explain the logic into the use of vListInsert but have not seen that explanation yet.

Geza Balazs: Thanks for that information. I don’t know if this is a Cortex-M … I asked and it is a Cortex-M4F. So I’ll send a note to the author and see if he thinks the interrupt priorities are correct.

For the third time, and as per your own findings, it appears you have a data corruption that is most likely to be caused by a bad interrupt priority. This has been highlighted to you twice already, and possible methods of trapping or confirming this have also been recommended (configASSERT(), stack overflow detection, etc.), but it does not appear that you have acknowledged this or followed it up and reported back but instead just keep repeating the same question – so I’m afraid I don’t consider it a good use of our time to continue this thread.

You don’t need to say something like “for the third time”. I told you the details and that this may be a race condition. Please read my comments more closely. Yes, the same question … I need some explanation of how the system uses this function so I can look for the race condition (A.K.A data corruption).

As was mentioned, there IS a common case to cause data corruption, that being incorrect interrupt priorities. You have not responded that you have verified that the interrupt priorities are infact correct. You seem very intent to figure out what is wrong with FreeRTOS (which has been very well tested), but not talking about looking at your usage, which is likely where the issue is.

I have sent an email to the author to check on the interrupt priorities. Your right … I failed to say that. I am not intent on finding any fault with FreeRTOS. If you carefully read my replies I have said that I have data corruption and (while I wait for a response for the author) I want to understand the logic of the use of how vListInsert is used so I can see if something else is causing this corruption … I would think that someone there would know that. I have been trying to look at my usage.

Have you performed the steps that Real Time Engineering Ltd asked in the third post? I will tell you that trying to understand the operation of vListInsert is almost certainly going to tell you NOTHING about the source of your data corruption, at that routine is the victim of the corruption, not the source. My experiance is that the problem you are seeing is almost always caused by having interrupt priorites incorrect or using the wrong API (calling FromISR from outside the ISR or not calling the FromISR from in an ISR). Defining configASSERT as suggested is a great way to look for these issues.

Yes, I performed the steps. But since this is not my code I have sent a message to the author to check the interrupt priorities. I have said NOTHING about something being wrong with FreeRTOS, in fact I said the opposite … that the author may have a race condition (but probably due to what you have said). I asked the author if he has ever run into this problem and he said no. I just noticed that this only happens if I am in the debugger. But he has not gotten back to me with an answer to the interrupt priority problem configASSERT is turned on and I have set a BP on the entry point that would be called but don’t hit that entry poing. I just want to understand how vListInsert is used. If you don’t know then please just say so. vListInsert is not a normal queue insert. I know the list should end with 0xffffffff but my list doesn’t (certenly due to the data corruption). I know vListInsert searches to add the new list after like lists but I don’t know the logic as to why this is done. I have listed the call stack leading up to vListInsert above. It looks like taking a semaphore is placing a task on the list. So I assume vListInsert is used for task scheduling … probably because the semaphore is not available.

Thanks for your help. The author got back with me. Since this only happens when we set breakpoints which lead up to the call to xSemaphoreTake() he thinks this is his race condition bug and I will stop working on it.

hi eddy, I understand your frustration, I have the same issue and I ended up in the same place. And to make this clear just at the beginning: I also do not think there is something wrong with the RTOS code. However it is very difficult to find the root cause. I figured out that I end up in the same loop because the item to be inserted is already inserted in the same list. Hint for the RTOS team: add a test of pvContainer like this: configASSERT(pxNewListItem->pvContainer == NULL); That means for me: it looks like I get twice the call of osSemaphoreWait on the same semaphore. or maybe that means: the task is executed even it is supposed to be suspended. I don’t think there is an issue with stack or data corruption like wrong pointers since the values look all sane. I tried to figure out, what could be wrong with the interrupt priorities but since all interrupts (except the one for osSystickHandler ) having values of the same or above configLIBRARYMAXSYSCALLINTERRUPTPRIORITY, I can’t see a possible cause of wrong priorities. Did you find the root cause of your issue? Just not having a break point is not working for me.

update: It seams like I got rid of the issue. I disabled USETICKLESSIDLE in the FreeRTOSConfig.h. I used generated code from STM32CubeMX and maybe there was something wrong in the implementation of the hooks required for this feature. I think this code caused some wrong thread resuming/sleeping which lead to this side effect.