Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Problems on ARM11

Posted by Nobody/Anonymous on August 10, 2006
We are using FreeRTOS3.2.4 ported in ARM11 (Freescale iMX31), using for hard
real time application. We are facing couple of problems

1) All of a sudden its hanged in vListRemove() function at below point

pxItemToRemove->pvContainer = NULL;
( pxList->uxNumberOfItems )--;
and if check "pxList:" memory address its out of memory space .
What would be the reason, not able to predicated.

2) My application required sending Q from interrupts @1mSec. But its slow down
my application and we misses some real time packet, which received in interrupt.

3) If you call portYield from ISR its generating exceptions and goes in to unmapped
memory area.

Can I replace FreeRTOS4.0.4 package with my old one and include that three HW
dependent port files only. Any thing extra i have to take care in port while upgrading
3.2.4 package to 4.0.4 package.

And please suggest if any thing special care i have to take while porting FreeRTOS
into ARM11 (its ported and working fine but some time its give problem as mention above)


RE: Problems on ARM11

Posted by Richard on August 10, 2006
> 1) All of a sudden its hanged in vListRemove() function at below point
>
> pxItemToRemove->pvContainer = NULL;
> ( pxList->uxNumberOfItems )--;
> and if check "pxList:" memory address its out of memory space .
> What would be the reason, not able to predicated.


Something in your system has corrupted the kernel maintained data structures. Most likely is that one of your tasks has overflowed its stack. Try identifying which task is short of stack space, or better still allocate more stack to each task.




> 2) My application required sending Q from interrupts @1mSec. But its slow
> down
> my application and we misses some real time packet, which received in
> interrupt.


Does the interrupt have to wake a task when the data is sent? If not then you can use any mechanism to send data from the interrupt, a simple buffer will be much faster.

Alternaitvely, if you are sending a lot of data, simply buffer the data then use a semaphore to wake the task so it can read the buffer. Semaphores do not cause any data to be copied and therefore are faster.



> 3) If you call portYield from ISR its generating exceptions and goes in to
> unmapped
> memory area.


I have not seen your port so don't know how you have implemented this, but generally on an ARM port calling portYIELD() would be expected to cause an error. Take a look at the ARM7 ports to see how they cause a context switch from an interrupt. Most define a macro (something like portEND_SWITCHING_ISR()) in which a new task is selected. This has the effect of the interrupt returning to the newly selected task immediately without the need to call portYIELD().

There are several ways of approaching this. You might also want to look at the ARM9 port, which saves the context of the task on entry to each interrupt. This means switching tasks within an interrupt is very easy, but has an overhead on the entry and exit code.


> Can I replace FreeRTOS4.0.4 package with my old one and include that three
> HW
> dependent port files only. Any thing extra i have to take care in port
> while upgrading
> 3.2.4 package to 4.0.4 package.


Don't think there is much - but the FreeRTOS.org WEB site contains a page on upgrading from 3.x.x to 4.x.x so take a look at that.



> And please suggest if any thing special care i have to take while porting
> FreeRTOS
> into ARM11 (its ported and working fine but some time its give problem as
> mention above)


I am not familiar with ARM11, but would image you will have to take care of how the cashe is used during context switches.

Regards.

RE: Problems on ARM11

Posted by Richard on August 14, 2006
I am facing some problem with xSemaphoreGiveFromISR in below mention code

void tachisr_handler (void)
{
uint32_t unGetData;
static portBASE_TYPE xTaskWokenSem1 = pdFALSE;
static portBASE_TYPE xTaskWokenSem2 = pdFALSE;

xTaskWokenSem1 = xSemaphoreGiveFromISR( hRangerEvent, xTaskWokenSem1 );
xTaskWokenSem2 = xSemaphoreGiveFromISR( hTachArrayEvent, xTaskWokenSem2 );


//clear the interrupt on GPIO3_0
GpioClearInt(FPGA_IMX_GPIO_ENGINE_NO,TACH_IRQ_PAD); //GPIO3_ISR.bits.GPIO_0 =1;*/

/*run other higher priority ready task*/
if((xTaskWokenSem1 == pdTRUE) || (xTaskWokenSem2 == pdTRUE))
{
taskYIELD();
}
return ;
}

In above code if i use "xTaskWokenSem1 " and "xTaskWokenSem2 " as non static we able to get the sem at respective task but it will be hang at vListRemove() or at vListInsert() after approx 10 to 15min. (the isr is invoked at every 2mSex continuously)
but if i made "xTaskWokenSem1 " and "xTaskWokenSem2 " as static my task will gets the sem only twice and goes in to permanent block.
i not able to understand what happening , can you please help me out from this problem.

RE: Problems on ARM11

Posted by Richard on August 14, 2006
[Moved from email]

Without being familiar with the port I can only make suggestions.

As per my previous response, it is probably not valid to call taskYIELD() within an ISR - but this depends on how you have implemented the function - which I do not know.

Have you looked at the ARM7 and ARM9 ports to see how they yeild from within an ISR. It is dependent on the compiler being used, but basically there will be a macro along the lines of portYIELD_FROM_ISR, or portEND_SWITCHING_ISR, etc.

Also, how have you declared the ISR? As a naked function? Or is it being called form an asm wrapper. I cannot see where you are saving the task context, maybe you are doing this prior to the function being called.

You need to look carefully at how you are defining the interrupts and compare this to the examples provided.

I have asked for a copy of your code but not received one. All I can do is guess.

Please use this support forum for all future correspondence.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner