Memory Problem when allocating quesues?

Hello, I see a problem with my queues under FreeRTOS V6.1.0 I’m compiling for ARM7 and execute it on an ARM Instruction Set Simulator (OVP, Open Virtual Platform)
But that should not be the Problem (I hope and think so). 1.)
It does not work when my code looks like below.
I create two queues with a length of 2 and 128 Bytes of size. I check if I receive a pointer to these queue and printf the values. #define uxQueueItemSize 128
#define uxQueueLengthDefault 2 tdAllQueueHandles *pAllQueueHandles = ( tdAllQueueHandles * ) pvPortMalloc( sizeof( tdAllQueueHandles ) );
pAllQueueHandles->qhDISPin   = xQueueCreate(uxQueueLengthDISP,   uxQueueItemSize);
pAllQueueHandles->qhRTBPAin  = xQueueCreate(uxQueueLengthRTBPA,  uxQueueItemSize);
 
printf(”%xn”, pAllQueueHandles->qhDISPin);
printf(”%xn”, pAllQueueHandles->qhRTBPAin);
 
if (pAllQueueHandles->qhDISPin   == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for Dispatcher!”);}
if (pAllQueueHandles->qhRTBPAin  == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for Real Time Board Protocol Abstraction!”);} The Simulation (execution of code) will show: 400009ec
40000b64
Info (OFFIS FreeRTOS task DISP) Starting Dispatcher task!
Info (OFFIS FreeRTOS task DISP) Stack left to use is: 40
Processor Exception (PC_PRX) Processor ‘CPU1’ 0x392c: e585100c str     r1,
Processor Exception (PC_WPX) No write access at 0xbc8c That is true, since oxbc8c is far from Flash or RAM memory of my simulated ARM! From what I see here right now, this is caused by trying to work with the queue in the Dispatcher task.
if ( xQueueReceive( pAllQueueHandles->qhDISPin,
( void * ) &ucQueueItem,
DISP_PERIOD
) == pdPASS ) 2.)
Now the really funny part! One could asume that somehow in case 1.) there is not enough memory or so (but the API did not
complain and did not return NULL as documented in case of not enough mem). But if I create even more queues
it suddenly works (at least for the first queues.):   tdAllQueueHandles *pAllQueueHandles = ( tdAllQueueHandles * ) pvPortMalloc( sizeof( tdAllQueueHandles ) );
  pAllQueueHandles->qhDISPin   = xQueueCreate(uxQueueLengthDISP,   uxQueueItemSize);
  pAllQueueHandles->qhRTBPAin  = xQueueCreate(uxQueueLengthRTBPA,  uxQueueItemSize);
  pAllQueueHandles->qhEGin     = xQueueCreate(uxQueueLengthEG,     uxQueueItemSize);
  pAllQueueHandles->qhUIin     = xQueueCreate(uxQueueLengthUI,     uxQueueItemSize);
  pAllQueueHandles->qhDSin     = xQueueCreate(uxQueueLengthDS,     uxQueueItemSize);
 
  printf(”%xn”, pAllQueueHandles->qhDISPin);
  printf(”%xn”, pAllQueueHandles->qhRTBPAin);
 
  if (pAllQueueHandles->qhDISPin   == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for Dispatcher!”);}
  if (pAllQueueHandles->qhRTBPAin  == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for Real Time Board Protocol Abstraction!”);}
  if (pAllQueueHandles->qhEGin     == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for Event Generator!”);}
  if (pAllQueueHandles->qhUIin     == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for User Interface!”);}
  if (pAllQueueHandles->qhDSin     == NULL){taskMessage(”F”, PREFIX, “Not enough memory to create queue for Data Storage!”);} The Simulation (execution of code) will show: 400009ec
40000b64
Info (OFFIS FreeRTOS task DISP) Starting Dispatcher task!
Info (OFFIS FreeRTOS task DISP) Stack left to use is: 40
Info (OFFIS FreeRTOS task EG) Starting Event Generator task!
Info (OFFIS FreeRTOS task EG) Stack left to use is: 70
Info (OFFIS FreeRTOS task EG) It is time to request readout of physical patient sensors.
Info (OFFIS FreeRTOS task DISP) Data in Dispatcher queue!
Info (OFFIS FreeRTOS task DISP) Package ID is: ucStartPeriodicPhysicalSensorRead!
Info (OFFIS FreeRTOS task DISP) Forwarded ucStartPeriodicPhysicalSensorRead to RTBPA.
Info (OFFIS FreeRTOS task DISP) Stack left to use is: 40
Info (OFFIS FreeRTOS task EG) Informed Dispatcher to process Periodic Physical Sensor Read.
Info (OFFIS FreeRTOS task DISP) No message for very long time. This doesn’t look good!!!!
Info (OFFIS FreeRTOS task DISP) Stack left to use is: 40

blablabla -> works perfect as desired! QUESTION:
Is it possible, that the FreeRTOS queue functionality is not working correctly? Maybe someone has an idea of the problem.
Otherwise I will have to step/debug through the FreeRTOS stuff. I would love to avoid that. Regards,
Frank Poppen

Memory Problem when allocating quesues?

> I see a problem with my queues under FreeRTOS V6.1.0
>
> I’m compiling for ARM7 and execute it on an ARM Instruction Set Simulator (OVP,
> Open Virtual Platform)
> But that should not be the Problem (I hope and think so). From eight years of experience of supporting FreeRTOS, people that say “I’m running FreeRTOS in a simulator and it does not work” have a problem with the simulator, not FreeRTOS.  I don’t know about your case, but my immediate assumption, reading your post, is that I don’t really want to get involved in anything on a simulator. Does this simulator simulate the core as a whole, or just the instruction set? > 1.)
> It does not work when my code looks like below.
> I create two queues with a length of 2 and 128 Bytes of size. I check if I receive
> a pointer to these queue and printf the values.
>
>  #define uxQueueItemSize 128
>  #define uxQueueLengthDefault 2
>
>  tdAllQueueHandles *pAllQueueHandles = ( tdAllQueueHandles * ) pvPortMalloc(
> sizeof( tdAllQueueHandles ) ); Can I assume that tdAllQueueHandles is an array of queue handles, in that it is an array of xQueueHandle variables?  Why are you dynamically allocating it and using a pointer to access it, rather than just declaring a variable of type tdAllQueueHandles?  Can you show how tdAllQueueHandles is defined? >  pAllQueueHandles->qhDISPin   = xQueueCreate(uxQueueLengthDISP, 
> uxQueueItemSize);
>  pAllQueueHandles->qhRTBPAin  = xQueueCreate(uxQueueLengthRTBPA,
> uxQueueItemSize); 128 for a queue item is massive.  You would probably be better off have a queue to pointers to 128 byte items, rather than queueing the items themselves. >  
>  printf(”%xn”, pAllQueueHandles->qhDISPin);
>  printf(”%xn”, pAllQueueHandles->qhRTBPAin);
>  
>  if (pAllQueueHandles->qhDISPin   == NULL){taskMessage(”F”, PREFIX, “Not enough
> memory to create queue for Dispatcher!”);}
>  if (pAllQueueHandles->qhRTBPAin  == NULL){taskMessage(”F”, PREFIX, “Not enough
> memory to create queue for Real Time Board Protocol Abstraction!”);}
>
>
> The Simulation (execution of code) will show:
>
> 400009ec
> 40000b64
> Info (OFFIS FreeRTOS task DISP) Starting Dispatcher task!
> Info (OFFIS FreeRTOS task DISP) Stack left to use is: 40 That is not much stack, if it is printed out in bytes rather than words.  Do you have stack overflow checking on? > Processor Exception (PC_PRX) Processor ‘CPU1’ 0x392c: e585100c str   
> r1,
> Processor Exception (PC_WPX) No write access at 0xbc8c
>
> That is true, since oxbc8c is far from Flash or RAM memory of my simulated ARM! The error output as it is does not tell me anything about what caused the problem, or what was being executed at the time the problem occurred. >
>>From what I see here right now, this is caused by trying to work with the queue
> in the Dispatcher task.
> if ( xQueueReceive( pAllQueueHandles->qhDISPin,
> ( void * ) &ucQueueItem,
> DISP_PERIOD
> ) == pdPASS ) Is the handle valid, has the handle been corrupted, is ucQueueItem on the stack (which would be bad), etc. >
> 2.)
> Now the really funny part! One could asume that somehow in case 1.) there is
> not enough memory or so (but the API did not
> complain and did not return NULL as documented in case of not enough mem). But
> if I create even more queues
> it suddenly works (at least for the first queues.): Sounds like a linker problem. How are the printf() messages being generated?  If you have 40 bytes of stack, and are using the standard GCC printf() function, then that is also a likely cause of an error. <snip> >
> QUESTION:
> Is it possible, that the FreeRTOS queue functionality is not working correctly? Extremely doubtful, as it has not changed in a while, and is in use by thousands of people as is.  However, it is the nature of software engineering that no guarantees can be given.  I always happy to be proven wrong. > Maybe someone has an idea of the problem.
> Otherwise I will have to step/debug through the FreeRTOS stuff. I would love
> to avoid that. You will not get far unless you are willing to debug your code.  In the time taken to write this post, you could have stepped through the function and found exactly where the exception was caused (if it is indeed in that function). Regards.

Memory Problem when allocating quesues?

Thank you very much for takling the time to answer. “> QUESTION: > Is it possible, that the FreeRTOS queue functionality is not working correctly? Extremely doubtful, as it has not changed in a while, and is in use by thousands of people as is. However, it is the nature of software engineering that no guarantees can be given. I always happy to be proven wrong.” This is the good answer to my most worries. I’m new to FreeRTOS and the project, so I have no feeling for how likely it is to trip over bugs in FreeRTOS itself. As I assumed you say it is very unlikely. After a weekend and some sleep I will now have a closer look at my code (was awake enough to write for help – not for heavy debuggin, sorry!) I will report, once I got news. P.S. your comments on Stack size, size of Package, etc. are all valid and about to change in my code. But I do not consider these to be part of the problem named.

Memory Problem when allocating quesues?

Sorry for this thread here. As I had planned anyways and as Richard suggested, I did some conceptual recoding which resulted in much smaller queues (8 Bytes instead of 128). The problem is gone. I do not know exactly what the problem originally was. But I believe it was a possibly simple copy&paste mistake when using queue pointers, which got fixed (unnoticed) when I did the recoding. Another solution could be that it now works because of the much smaller queues. But I consider this to be a lot less likely (according to Richard). So I finish this thread here. Sorry again for the noise.