Quality RTOS & Embedded Software

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




Loading

vListInsert does not do what the comments say

Posted by eddyq1 on June 14, 2016

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. */

vListInsert does not do what the comments say

Posted by heinbali01 on June 15, 2016

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?


vListInsert does not do what the comments say

Posted by rtel on June 15, 2016

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?


vListInsert does not do what the comments say

Posted by eddyq1 on June 15, 2016

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?


vListInsert does not do what the comments say

Posted by rtel on June 16, 2016

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.)?"


vListInsert does not do what the comments say

Posted by gezab on June 16, 2016

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().


vListInsert does not do what the comments say

Posted by eddyq1 on June 17, 2016

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.


vListInsert does not do what the comments say

Posted by eddyq1 on June 17, 2016

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.


vListInsert does not do what the comments say

Posted by rtel on June 17, 2016

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.


vListInsert does not do what the comments say

Posted by eddyq1 on June 17, 2016

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).


vListInsert does not do what the comments say

Posted by richard_damon on June 18, 2016

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.


vListInsert does not do what the comments say

Posted by eddyq1 on June 18, 2016

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.


vListInsert does not do what the comments say

Posted by richard_damon on June 18, 2016

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.


vListInsert does not do what the comments say

Posted by eddyq1 on June 18, 2016

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.


vListInsert does not do what the comments say

Posted by eddyq1 on June 21, 2016

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.


vListInsert does not do what the comments say

Posted by phuw on October 26, 2016

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.


vListInsert does not do what the comments say

Posted by phuw on October 27, 2016

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.


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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists