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

Delayed task lists crashes

Posted 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 crashes

Posted 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 crashes

Posted 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 crashes

Posted 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 crashes

Posted 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 crashes

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


[ 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