Runtime error in bf561 COREB FreeRTOS implementation when pointing to structure data

Question

I've a runtime error in several function when it try to access structure data generally pass as a parameter to the function.

the first instance of the problem is:

signed portBASE_TYPE xQueueGenericReceive( xQueueHandle pxQueue, void * const p\

vBuffer, portTickType xTicksToWait, portBASE_TYPE xJustPeeking )

{

..............



if( pxQueue->uxMessagesWaiting > ( unsigned portBASE_TY\

PE ) 0 )



.......................



}

where pxQueue is a structure:

typedef xQUEUE * xQueueHandle;

with:

typedef struct QueueDefinition

{

        signed char *pcHead;                            /*< Points to the begin\

ning of the queue storage area. */

    signed char *pcTail;                            /*< Points to the byte \

at the end of the queue storage area.  Once more byte is allocated than necessa\

ry to store the queue items, this is used as a marker. */



        signed char *pcWriteTo;                         /*< Points to the free \

next place in the storage area. */

        signed char *pcReadFrom;  
                    /*< Points to the last \

place that a queued item was read from. */


        xList xTasksWaitingToSend;                              /*< List of tas\

ks that are blocked waiting to post onto this queue.  Stored in priority order.\

*/
        xList xTasksWaitingToReceive;                   /*< List of tasks that \

are blocked waiting to read from this queue.  Stored in priority order. */


        volatile unsigned portBASE_TYPE uxMessagesWaiting;/*< The number of ite\

ms currently in the queue. */
        unsigned portBASE_TYPE uxLength;                /*< The length of the q\

ueue defined as the number of items it will hold, not the number of bytes. */
        unsigned portBASE_TYPE uxItemSize;              /*< The size of each it\

ems that the queue will hold. */


        signed portBASE_TYPE xRxLock;                   /*< Stores the number o\

f items received from the queue (removed from the queue) while the queue was lo\

cked.  Set to queueUNLOCKED when the queue is not locked. */
        signed portBASE_TYPE xTxLock;                   /*< Stores the number o\

f items transmitted to the queue (added to the queue)

while the queue was locke\

d.  Set to qu.......................



}

where pxQueue is a structure:

typedef xQUEUE * xQueueHandle;

with:

typedef struct QueueDefinition

{

        signed char *pcHead;                            /*< Points to the begin\

ning of the queue storage area. */

    signed char *pcTail;                            /*< Points to the byte \

at the end of the queue storage area.  Once more byte is allocated than necessa\

ry to store the queue items, this is used as a marker. */



        signed char *pcWriteTo;                         /*< Points to the free \

next place in the storage area. */

        signed char *pcReadFrom;  
                    /*< Points to the last \

place that a queued item was read from. */


        xList xTasksWaitingToSend;                              /*< List of tas\

ks that are blocked waiting to post onto this queue.  Stored in priority order.\

*/
        xList xTasksWaitingToReceive;                   /*< List of tasks that \

are blocked waiting to read from this queue.  Stored in priority order. */


        volatile unsigned portBASE_TYPE uxMessagesWaiting;/*< The number of ite\

ms currently in the queue. */
        unsigned portBASE_TYPE uxLength;                /*< The length of the q\

ueue defined as the number of items it will hold, not the number of bytes. */
        unsigned portBASE_TYPE uxItemSize;              /*< The size of each it\

ems that the queue will hold. */


        signed portBASE_TYPE xRxLock;                   /*< Stores the number o\

f items received from the queue (removed from the queue) while the queue was lo\

cked.  Set to queueUNLOCKED when the queue is not locked. */
        signed portBASE_TYPE xTxLock;                   /*< Stores the number o\

f items transmitted to the queue (added to the queue)

while the queue was locke\

d.  Set to queueUNLOCKED when the queue is not locked. */



} xQUEUE;
eueUNLOCKED when the queue is not locked. */



} xQUEUE;

the runtime error is:

.....
COREB: start xQueueGenericReceive                                           
COREB: execption 24 addr 3c00384                                            
COREB: coreb dump stack                                                     
COREB: found fp: ff700900                                                   
COREB:  call frame 0 -12 feb055e2                                           
COREB:  call frame 0 -11 00000000                                           
COREB:  call frame 0 -9 00000000                                            
COREB:  call frame 0 -8 ff7008d0    

......

Similarly, I've the same problem with the following function:

void vListRemove( xListItem *pxItemToRemove )

{

xList * pxList;



   pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious;

        pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext;

}

where pxItemToRemove->pxPrevious can be read but not pxItemToRemove->pxNext->pxPrevious

it structure is:

struct xLIST_ITEM

{

     portTickType xItemValue;                                /*< The value b\

eing listed.  In most cases this is used to sort the list in descending order. \

*/

        volatile struct xLIST_ITEM * pxNext;    /*< Pointer to the next xListIt\

em in the list. */

        volatile struct xLIST_ITEM * pxPrevious;/*< Pointer to the previous xLi\

stItem in the list. */

        void * pvOwner;                                                 /*< Poi\

nter to the object (normally a TCB) that contains the list item.  There is ther\

efore a two way link between the object containing the list item and the list i\

tem itself. */

        void * pvContainer;                                             /*< Poi\

nter to the list in which this list item is placed (if any). */

};

typedef struct xLIST_ITEM xListItem;            /* For some reason lint wants t\

his as two separate definitions. */

the runtime error is:

COREB: got to vTaskDelete                                                   
COREB: pxTCB GLI prev: a5a5a5a5                                             
COREB: sent to list: 3d02004                                                
COREB: list_rem px prev: a5a5a5a5                                           
COREB: execption 24 addr 3c05444                                            
COREB: coreb dump stack                                                     
COREB: found fp: ff7008fc                                                   
COREB:  call frame 0 -12 feb055e2                                           
COREB:  call frame 0 -11 00000000                                           
COREB:  call frame 0 -9 00000000                                            
COREB:  call frame 0 -8 ff7008cc                                            
COREB:  call frame 0 -7 ff700ff4

Thank you in advance.

William

Debugging further with gdb I've got pxQueue:

p/x *pxQueue

$9 = {pcHead = 0xadadadad, pcTail = 0xadadadad, pcWriteTo = 0xadadadad,

  pcReadFrom = 0xadadadad, xTasksWaitingToSend = {

    uxNumberOfItems = 0xadadadad, pxIndex = 0xadadadad, xListEnd = {

      xItemValue = 0xadad, pxNext = 0xadadadad, pxPrevious = 0xadadadad}},

  xTasksWaitingToReceive = {uxNumberOfItems = 0xadadadad,

    pxIndex = 0xadadadad, xListEnd = {xItemValue = 0xadad,

      pxNext = 0xadadadad, pxPrevious = 0xadadadad}},

  uxMessagesWaiting = 0xadadadad, uxLength = 0xadadadad,

  uxItemSize = 0xadadadad, xRxLock = 0xadadadad, xTxLock = 0xadadadad}

it is really strange, all the parameters of the structure have the same value: 0xadadadad

when I debug further and look at the semaphore creation as a queue object in the create queue function I've got normal values:

 p *pxNewQueue

$7 = {pcHead = 0x3d17000 "", pcTail = 0x3d17000 "", pcWriteTo = 0x3d17000 "", 

  pcReadFrom = 0x3d17000 "", xTasksWaitingToSend = {uxNumberOfItems = 0, 

    pxIndex = 0x3d16018, xListEnd = {xItemValue = 65535, pxNext = 0x3d16018, 

      pxPrevious = 0x3d16018}}, xTasksWaitingToReceive = {uxNumberOfItems = 0, 

    pxIndex = 0x3d1602c, xListEnd = {xItemValue = 65535, pxNext = 0x3d1602c, 

      pxPrevious = 0x3d1602c}}, uxMessagesWaiting = 0, uxLength = 1, 

  uxItemSize = 0, xRxLock = -1, xTxLock = -1}

Thanks,

William

Please format your code. Nobody likes reading a question that shows zero effort. — bitmask, Feb 07 '12 at 00:43
Have you checked all pointers to make sure none of them are NULL? — Some programmer dude, Feb 07 '12 at 07:25
Hey bit Mask can't you see it is formatted... I don't like you said I put zero effort, if you look again you can see that I put the relevant code and removed non related code. I've put for each structure issue: the code in the function, the related structure, the output of the runtime debugging. What more do you want for clarity? — william pagnon, Feb 07 '12 at 22:37
Hi Joachim, do you mean a conditional check of the pointer? the problem is that as soon as I try to read the pointer I've got the runtime error I show above. I can read its address though — william pagnon, Feb 07 '12 at 22:40
BTW: if(pxQueue == NULL) return not NULL if(pxQueue->uxMessagesWaiting == NULL) does runtime error. — william pagnon, Feb 08 '12 at 01:12
0xADADADAD is a specific pattern to show that you are using uninitialized memory. — Mark Lakata, Jul 17 '13 at 14:13

score 0 · Answer 1 · edited Feb 24 '12 at 14:11

0

What is it you are trying to do, and how. What is COREB?

Are the functions from which you have posted snippets of code unmodified from the official FreeRTOS code? The code is normally compiled and linked into an executable, so you would not get any such run-time error. If there was any problem you would only get compile/link errors. If you are getting run-time errors then are you trying to interpret the code rather than compile it?

edited Feb 24 '12 at 14:11

Trygve Laugstøl

7,440
2
36
40

answered Feb 07 '12 at 09:40

Richard

1

FreeRTOS do not support Analog device Blackfin unfortunately..... the BF561 is a dual core, I'm running the freeRTOS on coreB (the second core) using a try of FreeRTOS for blackfin by a contributor (see your website) compiled in VDSP I transformed it to GCC compiler. There have been a lot of errors in this contribution but now I'm close to have it work. there is just problem left with queue and list structure. maybe an alignment problem..... due to missing tag function and hooking function implementation etc ... I had to put my hand on. Trust me I would have preferd not to – william pagnon Feb 07 '12 at 22:44
actually, you could really help me as you are from free RTOS. I think the problem come from xTaskCallApplicationTaskHook( pxCurrentTCB, pxCurrentTCB->pxStack); I I've put ->pxStack but I must be wrong. what point the pvParameter in the TCB structure? – william pagnon Feb 08 '12 at 04:42

score 0 · Answer 2 · answered Mar 14 '12 at 11:36

I Found the answer,

Basically as they was no doc in FreeRTOS about it, I used gdb and look for the pvParameter during task creation and look where it has been stored in the stack. then when I trigger the task with the taskhook function I give back the parameter:

void *param = *(pxCurrentTCB->pxTopOfStack+31);

                //        xTaskCallApplicationTaskHook( pxCurrentTCB, pxCurrent\
TCB->pxTopOfStack);                                                             
                xTaskCallApplicationTaskHook( pxCurrentTCB,param );

then when the queue and lis for the semafor are called, it point to the right address. and the data structure is retrieved.

Runtime error in bf561 COREB FreeRTOS implementation when pointing to structure data

2 Answers2