Post Go back to editing

Runtime error in bf561 COREB when pointing to structure data

Hi, 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 queueUNLOCKED 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

  • Hi William,

    It seems a unalignment issue. Can you print pxQueue and pxQueue->uxMessagesWaiting address to see if it is not 4 byte aligned.

    You could avoid using 16bit short type in data structure at first.

    -steven

  • Hi Steven,

    adding in the code:

    coreb_msg("addr pxQueue = %x\n",&pxQueue);

    coreb_msg("addr pxQueue->msgWait = %x\n",&(pxQueue->uxMessagesWaiting));

    I've got when I run:

    COREB: addr pxQueue = ff7009b0                                            

    COREB: addr pxQueue->msgWait = a5a5a5dd

    the runtime error happen just after





    COREB: execption 24 addr 3c003b6                                          
    COREB: coreb dump stack                                                   

    COREB: found fp: ff7008fc

    which point to :

    if( pxQueue->uxMessagesWaiting > ( unsigned portBASE_TYPE ) 0 )

    a5a5a5dd the address of pxQueue->uxMessagesWaiting seem to be reserved which will explain why it crash. Don't know why it get this address allocation though

    thank you

    William

  • Hi William,

    You should print coreb_msg("addr pxQueue = %x\n",pxQueue);  &pxQueue is a local point address in stack.

    -steven

  • Hi Steven,

    Replacing  by coreb_msg("addr pxQueue = %x\n",pxQueue); I've got:

    addr pxQueue = a5a5a5a5

    I had a bit more look around today. I think the problem is link to the time I do the hook function:

    xTaskCallApplicationTaskHook( pxCurrentTCB, pxCurrentTCB->pxStack);

    the second argument should be the pvParameters of the task stored in the TCB but I'm not sure where it is. When I looked closer I found that:

    .....

        coreb_msg("Start port initialise stack fnc \n" );
        ulAddress = ( unsigned portLONG ) pxCode;

        for (i = 14; i > 0; i--) {

            // R0 - R7, P0 - P5 value - caller's incoming argument #1     
            *--pxTopOfStack = (portSTACK_TYPE) pvParameters;
            //   coreb_msg("pxTopOfStack: %x \n",pxTopOfStack );          

        }

    .....

    Where I realised that the stack start from the top and decrement. as it store the pvParameters at the top of it I then changed to:

    xTaskCallApplicationTaskHook( pxCurrentTCB, pxCurrentTCB->pxTopOfStack);

    this time, when I run, the semaphore is not found anymore and go to another loop as waiting state (do not go in the queue function) in :

    static portTASK_FUNCTION(LED_blink_thread, Param)

        coreb_msg("start LED_blink_thread\n");

        task_params_list_t *p = (task_params_list_t *)Param;

        coreb_msg("got parameters\n");
        int lite = p->LED;
       

    xSemaphoreHandle sem = p->event;

      if (sem != (xSemaphoreHandle)0)                                 // is t\
    he semaphore pointer is valid                                             
        {
            coreb_msg("semaphore pointer is valid\n");
                while(1)
                {
                    // Button task: sem is non-NULL, pend on it for ever  
                    while( xSemaphoreTake( sem, portMAX_DELAY ) != pdTRUE );

    .....

    here xSemaphoreTake( sem, portMAX_DELAY ) is defined as :

    #define xSemaphoreTake( xSemaphore, xBlockTime )            xQueueGenericRe\

    ceive( ( xQueueHandle ) ( xSemaphore ), NULL, ( xBlockTime ), pdFALSE )

    and it is in xQueueGenericReceive function I've the runtime error.

    So I think that maybe if I'm sure of where the pvParameters are stored in the TCB, then I will point to the right parameters.

    BTW: are you oblige to reboot after running ./icc_loader -f -e test_ad1836_driver? is there is a when to reload a new test_ad1836_drive without rebooting linux?

    Thanks

    William

  • Hi William,

    You can reload test_ad1836_driver without reboot, but if you want to ./icc_load -l icc, you need reboot due to coreb cannot be reset and execute from start_entry on the fly.

    -steven

  • Please use the source code in 2011R1 release other than the SVN trunk.

    We update the SVN trunk to a new kernel version without any testing yet.

  • Hi Steven,

    about the load function:

    Sorry you are right, you can reload the file  but when I want to download via tftp a new file freshly compiled I've got:

    ------------[ cut here ]------------                                      
    WARNING: at net/sched/sch_generic.c:255 _dev_watchdog+0x200/0x208()       
    NETDEV WATCHDOG: eth0 (smc91x): transmit queue 0 timed out                
    Modules linked in:                                                        
    Hardware Trace:                                                           
       0 Target : <0x00123664> { _dump_stack + 0x0 }                          
    Source : <0x0001170a> { _warn_slowpath_common + 0x46 } CALL pcrel    
       1 Target : <0x0001170a> { _warn_slowpath_common + 0x46 }               
    Source : <0x00031d1a> { _print_modules + 0x4e } RTS                  
       2 Target : <0x00031d14> { _print_modules + 0x48 }                      
    Source : <0x00123834> { _printk + 0x14 } RTS                         
       3 Target : <0x00123830> { _printk + 0x10 }                             
    Source : <0x00012384> { _vprintk + 0x164 } RTS                       
       4 Target : <0x00012362> { _vprintk + 0x142 }                           
    Source : <0x00012492> { _vprintk + 0x272 } JUMP.S                    
       5 Target : <0x00012492> { _vprintk + 0x272 }                           
    Source : <0x00011f9e> { _console_unlock + 0x1e6 } RTS                
       6 Target : <0x00011f96> { _console_unlock + 0x1de }                    
    Source : <0x00011f88> { _console_unlock + 0x1d0 } IF CC JUMP pcrel   
       7 Target : <0x00011f78> { _console_unlock + 0x1c0 }                    
    Source : <0x00011f44> { _console_unlock + 0x18c } IF CC JUMP pcrel   
       8 Target : <0x00011f42> { _console_unlock + 0x18a }                    
    Source : <0x00011f34> { _console_unlock + 0x17c } IF CC JUMP pcrel (BP)   
       9 Target : <0x00011f12> { _console_unlock + 0x15a }                    
    Source : <0x00028d36> { _up + 0x3e } RTS                             
      10 Target : <0x00028d30> { _up + 0x38 }                                 
    Source : <0x00028d22> { _up + 0x2a } IF CC JUMP pcrel (BP)           
      11 Target : <0x00028cf8> { _up + 0x0 }                                  
    Source : <0x00011f0e> { _console_unlock + 0x156 } JUMP.L             
      12 Target : <0x00011ef0> { _console_unlock + 0x138 }                    
    Source : <0x00011e1c> { _console_unlock + 0x64 } IF CC JUMP pcrel    
      13 Target : <0x00011dec> { _console_unlock + 0x34 }                     
    Source : <0x00011e4c> { _console_unlock + 0x94 } IF CC JUMP pcrel (BP)
      14 Target : <0x00011e44> { _console_unlock + 0x8c }                     
    Source : <0x0001192e> { __call_console_drivers + 0x62 } RTS          
      15 Target : <0x00011928> { __call_console_drivers + 0x5c }              
    Source : <0x00011902> { __call_console_drivers + 0x36 } IF CC JUMP pcrel  
    Stack info:                                                               
    SP: [0x0019dd8c] <0x0019dd8c> /* kernel dynamic memory */                
    FP: (0x0019ddf8)                                                         
    Memory from 0x0019dd80 to 0019e000                                       

    0019dd80: 0019ddd8  0019dd8c  0001170a [0019ddd8] 0001170e  0019ddd8  00162590 

    0019dda0: 00162590  000000ff  000e4b60  00011778  0018efdc  00000000  000000fa 

    0019ddc0: 00000000  30e03500  000000ce  000000ce  00000009  0019ddd8 <001625a8>

    0019dde0: 000e4b60  00000000  00028502  0019ddfc  0204a400  0015319c (00000000)>

    0019de00: 00186ee0  0019de44  000e4960  00000100  00200200  0018efdc  000000ce 

    0019de20:<00006c8a> 0018cda4  ffffffc0  00190178  0019c000  00187cec  00187aec 

    0019de40: 001876ec  0019de44  0019de44  0000000a <0001600c> 00186dc0  00000004 

    0019de60: 00000001  00000004  00000100  00000001  0019c008  0019c008  00000006 

    0019de80: 00000000  02b10258  0017d0a0  ffa00408  00195aa8  0019c008  0019c008 

    0019dea0: 00000000  00000000  02b10258  ffa0180a  ffc00014  00000000  ffa00d16 

    0019dec0: ffa00120  00000000  00000000  00000000  00000000  ffa00144  00008050 

    0019dee0: 00000000  028f0000  02903332  ffa00144 <ffa00358> 00000006  02002020 

    0019df00: ffa0180c  0290be28  ffa0180a  00000000  00000000  00009639  00000000 

    0019df20: 00000000  00000000  00000000  00000000  00000000  00000000  00000000 

    0019df40: 00000000  00000000  00000000  00000000  00000004  00000000  02973eb8 

    0019df60: 02807128  0019e000  0017d0a0  ffa00120  0019c008  0019c008  0018d5ec 

    0019df80: ffa00a90  ffa00120  00000000  00000000  02b10258  00000065  00000008 

    0019dfa0: 0000ffff  0000ffff  ffa00a90  00000006  0017d00c  001b3420  00000000 

    0019dfc0: 0019e622  00188620  0017d000  0017d00c  001b3420  0014e72c  001b0a50 

    0019dfe0: 00000019  0019e1e8  001b3420  001a4ffe  ffe00000  03f9fe5c  03f9ff80 

    Return addresses in stack:                                                
    address : <0x001625a8> /* kernel dynamic memory */                    
       frame  1 : <0x0001a06c> { _run_timer_softirq + 0xf0 }                  
    address : <0x00006c8a> { _bfin_coretmr_interrupt + 0x12 }             
    address : <0x0001600c> { ___do_softirq + 0x7c }                       
    address : <0xffa00358> { _cpu_idle + 0x30 }                           
    ---[ end trace 6845f49b549503e6 ]---          

    is ICC conflicting with the Ethernet ?

  • Hi William,

    ICC will not conflict with the network. Which kernel version are you using now? I didn't meet this kernel warning before.

    -steven

  • Hi Steven,

    I'm using the following version:

    Image Name:   bf561-0.3-3.1.0-ADI-2012R1-pre-s

  • Hi William,

    Did it appear in 2011 release version. And did it appear every time or occasionally?