FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [April 2013 Threads] Delayed task lists crashesPosted by Rakesh on April 19, 2013 The crash occurs in the following block called from vTaskIncrementTick. The data suggests that pxTCB is corrupt resulting in a dabort exception. Taking that one step further, there is most likely a problem in the delayed task list.
Can anyone suggest if any fix was made in the delayed task lists. We are using the v6.0.4 version of free rtos code. Please advice?
#define prvCheckDelayedTasks() { register tskTCB *pxTCB; while( ( pxTCB = ( tskTCB * ) listGET_OWNER_OF_HEAD_ENTRY( pxDelayedTaskList ) ) != NULL ) { if( xTickCount < listGET_LIST_ITEM_VALUE( &( pxTCB->xGenericListItem ) ) ) { break; } vListRemove( &( pxTCB->xGenericListItem ) ); /* Is the task waiting on an event also? */ if( pxTCB->xEventListItem.pvContainer ) { vListRemove( &( pxTCB->xEventListItem ) ); } prvAddTaskToReadyQueue( pxTCB ); } }
RE: Delayed task lists crashesPosted by Richard on April 20, 2013 I don't think that code has been touched - but all the same it is always best to be using the latest version of code. Upgrading is simply a matter of dropping the latest files over the older files in your project.
Which CPU are you using? The symptom you describe is normally associated with incorrect interrupt priority assignments on a Cortex-M core.
Have you read the following two pages:
http://www.freertos.org/FAQHelp.html http://www.freertos.org/RTOS-Cortex-M3-M4.html
Regards.
RE: Delayed task lists crashesPosted by Rakesh on April 22, 2013 We are using the LPC2388 CPU. Where are the interrupt priority assignments set to. The configMAX_SYSCALL_INTERRUPT_PRIORITY is not defined anywhere in our project. We use the VIC configure API tos et the priorities of the interrupt:
#define VIC_SLOT_MAX15u
#defineVIC_SLOT_RTOS0u // DO NOT CHANGE #define VIC_SLOT_TIMER0 (VIC_SLOT_RTOS) // TIMER0 alias for non-RTOS builds !!! #define VIC_SLOT_UART0VIC_SLOT_RTOS #define VIC_SLOT_CANVIC_SLOT_RTOS #define VIC_SLOT_BOD 3u #define VIC_SLOT_DMA4u #define VIC_SLOT_UART1VIC_SLOT_RTOS #define VIC_SLOT_USB6u #define VIC_SLOT_SD_MMC7u #define VIC_SLOT_EINT18u #define VIC_SLOT_TIMER19u #define VIC_SLOT_EINT010u #define VIC_SLOT_WATCHDOG 11u #define VIC_SLOT_RTC 11u #define VIC_SLOT_UART2VIC_SLOT_RTOS #define VIC_SLOT_UART3VIC_SLOT_RTOS #define VIC_SLOT_SSP114u #define VIC_SLOT_TIMER214u #define VIC_SLOT_TIMER315u
/*---------------------------------------------------------------------------*/ /*! * Configures the LPC2000 VIC controller for an interrupt source * * @param u8SlotNo : The slot allocated for this interrrupt source * @param u32Channel : The interrupt source channel number * @param *pISR : Address of the ISR * * @return uint8_t:Error code */ /*---------------------------------------------------------------------------*/ uint8_t VIC_Configure(uint8_t u8SlotNo, uint32_t u32Channel, uint32_t* pISR) { uint32_t *pSFR = NULL;
if ((u8SlotNo > VIC_SLOT_MAX) || (u32Channel > VIC_CHANNEL_MAX) || (pISR == NULL)) { // error, invalid VIC slot or channel or bad fn ptr return (1); }
#ifdef __TARGET_PROCESSOR_LPC2388 // 23xx devices don't have a mapping, instead they increase number of channels // to 32 and assume a 1 to 1 map. Assume SLOT=PRIORITY
// Configure the priority number for this interrupt source pSFR = (uint32_t*)(&VICVectPriority0) + u32Channel; if (u8SlotNo < 0x10) // is the slot within the max range (0x0 to 0xF) ? *pSFR = (uint32_t)u8SlotNo; // set priority based on allocated slot else *pSFR = 0x0000000F; // out of range, so default at lowest priority level
// Assign the ISR to the VIC address table pSFR = (uint32_t*)(&VICVectAddr0) + u32Channel; *pSFR = (uint32_t)pISR;
// Enable the VIC channel VICIntEnable |= (1 << u32Channel);
#else
// Configure the slot number for this interrupt source pSFR = (uint32_t*)(&VICVectCntl0) + u8SlotNo; *pSFR = ((u32Channel & 0x1F) | (1 << 5));
// Assign the ISR to the VIC slot pSFR = (uint32_t*)(&VICVectAddr0) + u8SlotNo; *pSFR = (uint32_t)pISR;
// Enable the VIC channel VICIntEnable |= (1 << u32Channel); #endif #endif VIC_TRACE("VIC Channel %d configured\n", u32Channel);
// success return (0); }
RE: Delayed task lists crashesPosted by MEdwards on April 22, 2013 That is an ARM7 part so will not have a configKERNEL_INTERRUPT_PRIORITY setting as it does not support interrupt nesting. configKERNEL_INTERRUPT_PRIORITY is only needed when interrupt nesting is supported (Cortex-M3, RX, etc)
RE: Delayed task lists crashesPosted by Rakesh on April 24, 2013 We did lot of diagnostics in our application to report the stack dump or trace and the check points trace for the tasks created. From the diagnostics what we find is the code jumps from one place to another without executing the code in between the jump. It is a random jump in a particular task which has many nested while loops. This is causing another task to get watchdog as well. Do you know why would the code jump from one location to another which did not have any continue or goto instruction. Could it be a stack corruption issue? We tried to reproduce the issue in our test bench but does not happen. We can see this problem only in the customer devices which runs in teh field. This problem does not happen frequently but is random and happens may be once in a while not frequent.
Please suggest what could be the root cause of code jumping in a task?
RE: Delayed task lists crashesPosted by Richard on April 25, 2013 When the task is executing without any context switches it is just a normal C function - in which case the processor will just execute the instructions and behave exactly as dictated by the instructions it is executing. If a context switch is occurring then it is *possible* but *unlikely* that the task is being switched out and having its program counter saved, the program counter is somehow being corrupted while it is switched out, and when it starts running again the restored program counter continues from the wrong place. It the highly unlikely event that that occurred it is again *unlikely* that a corrupted program counter would cause the task to continue within the same task code. It would be much more likely that a corrupted program counter would just cause a major crash as the processor started to access memory that didn't contain instructions, a null address, or a misaligned address.
So unfortunately I don't think I have a realistic scenario that would cause what you are seeing.
Could there be an environmental issue when in the field that is not present on the test bench. For example, maybe the power is browning out, or maybe there is some external radiated interference, or maybe something is causes an error on the address bus (is the delta in the addresses between the point of the jump and the destination of the jump a power of2?).
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|