New Port attempted is hanging(Rowley XStudio)

ozsmit wrote on Monday, October 22, 2012:


I am new to FreeRTOS.  I am trying to create a simple blinky application to test out my hardware target, MTek MV8750(ARM926EJ-S).  I followed the instructions “Creating a New FreeRTOS Port” from  FreeRTOS-porting-guide.html page.

I have the Rowley CrossStudio compiling and linking.  I used the LPC23xx project as a reference only. And,

The code hangs in the following thread:

From Main:

    -> /* Create the idle task without storing its handle. */
    -> xReturn = xTaskCreate( prvIdleTask, ( signed char * ) “IDLE”, tskIDLE_STACK_SIZE, ( void * ) NULL, ( tskIDLE_PRIORITY | portPRIVILEGE_BIT ), NULL );

        -> pxNewTCB->pxTopOfStack = pxPortInitialiseStack( pxTopOfStack, pxTaskCode, pvParameters );
        -> prvAddTaskToReadyQueue( pxNewTCB );

This eventuall calls: 

void vListInsertEnd( xList *pxList, xListItem *pxNewListItem )
volatile xListItem * pxIndex;

/* Insert a new list item into pxList, but rather than sort the list,
makes the new list item the last item to be removed by a call to
pvListGetOwnerOfNextEntry.  This means it has to be the item pointed to by
the pxIndex member. */
pxIndex = pxList->pxIndex;


pxNewListItem->pxNext = pxIndex->pxNext;

THE ABOVE LINE indexes memory off in the weeds.

I implemented the stub, pxPortInitializeStack() like the web page says.  I simply copied the contents from the LPC23xx port.c file.

Its obvious that my FreeRTOS is missing some #defines, etc that are crucial to setting up memory.

SHould I stay on this path?  Or should I try to convert one of the ARM7 projects to my ARM926EJ-S platform.

Thanks in Advance,


edwards3 wrote on Tuesday, October 23, 2012:

The ARM7 and ARM9 ports are all the same except for the peripheral timers used to generate the tick interrupt, and the interrupt controller that vectors the interrupts.  You should be able to take an ARM7 or ARM9 port that uses the same compiler and convert that by just changing those two components to be correct for your chip.

ozsmit wrote on Tuesday, October 23, 2012:

Thank you …

Will give that a try.

ozsmit wrote on Wednesday, October 24, 2012:

I gave that a try and it seems to be working a lot better.  I am seeing another issue now and wondering if its because I havent implemented the timer tick for my hardware yet.

I used …\CrossWorks Projects\FreeRTOSV7.2.0\FreeRTOS\Demo\ARM7_LPC2138_Rowley as my ARM7 Template.

When I step through the code it hangs in task .c on this last line:

#if ( INCLUDE_vTaskDelay == 1 )

void vTaskDelay( portTickType xTicksToDelay )
portTickType xTimeToWake;
signed portBASE_TYPE xAlreadyYielded = pdFALSE;

/* A delay time of zero just forces a reschedule. */
if( xTicksToDelay > ( portTickType ) 0U )

/* A task that is removed from the event list while the
scheduler is suspended will not get placed in the ready
list or removed from the blocked list until the scheduler
is resumed.

This task cannot be in an event list as it is the currently
executing task. */

/* Calculate the time to wake - this may overflow but this is
not a problem. */
xTimeToWake = xTickCount + xTicksToDelay;

/* We must remove ourselves from the ready list before adding
ourselves to the blocked list as the same list item is used for
both lists. */
vListRemove( ( xListItem * ) &( pxCurrentTCB->xGenericListItem ) );
prvAddCurrentTaskToDelayedList( xTimeToWake );
xAlreadyYielded = xTaskResumeAll();

/* Force a reschedule if xTaskResumeAll has not already done so, we may
have put ourselves to sleep. */
if( xAlreadyYielded == pdFALSE )
Hangs here: portYIELD_WITHIN_API();   

The first question I have is will this even execute if I had the timer hardware setup already?

The second question is I cant find doucmentation on this MACRO.  And its not in the portMacro.h file that belongs to this project.  I did however find a definition of it in  the …\portable\gcc\arm_cm3_mpu  project.

I wonder why I didnt get a compiler error for this undefined macro.



edwards3 wrote on Wednesday, October 24, 2012:

The ARM 7 port does not provide a separate portYIELD_WITHIN_API function, so the the macro is just defined to be the same as portYIELD. That is done in freertos.h.

If the tick time is not running then a task that calls a delay function will never unblock.

ozsmit wrote on Tuesday, November 06, 2012:

I have ported my timers code and Interrupt Vector code and some how I am still not vectoring to the IRQ_Handler.  I must be missing a intializtion of some kind on my ARM926EJ device.

However, I still see the FreeRTOS  blow up after my timers initialization. 

portBASE_TYPE xPortStartScheduler( void )
/* Start the timer that generates the tick ISR.  Interrupts are disabled
here already. */

/* Start the first task. */

/* Should not get here! */
return 0;

After setting up the timer, code hangs on call to vPortISRStartFirstTask();.

void vPortISRStartFirstTask( void )
    E52DB004    str r11, !
    E28DB000    add r11, sp, #0

Will this fix itself once Timer Interrupt occurs like previous issue, or is something else wrong?


davedoors wrote on Wednesday, November 07, 2012:

Where did the code for StartFristTask() come from? On an ARM7 it should call portRESTORE_CONTEXT, which has more than two lines of assembler.

ozsmit wrote on Wednesday, November 14, 2012:


Thanks for reply but I found the probelm… Code was vectoring to High Vectors instead of 0x00000018 IRQ.   But to answer your question:  Its does… its just that that was the assembly.

void vPortISRStartFirstTask( void )
/* Simply start the scheduler.  This is included here as it can only be
called from ARM mode. */


ozsmit wrote on Wednesday, November 14, 2012:


I have succefully plummed in the TImer Interrupt and added the Interrupt vector to my FreeRTOS port.  I now get interrupts from the timer and the tickcounter is incremented, however depending on where I set my breakpoints I end up getting anywhere between 1 - 10 ticks before the system hangs.

It either hangs in StackOverflow  endleep loop or an UNDEF IRQ Vector is generated.

I used the following sample project files:

With Cross Studio.

What can be causing this problem?  Where can I get trouble shooting instructions other than the FreeRTOS manuals?

Thanks In Advance,

ozsmit wrote on Thursday, November 15, 2012:

I wanted to add another bit of information.

I am calling :

void vTickISR( void ) __attribute__((naked));
void vTickISR( void )
/* Save the context of the interrupted task. */

/* Increment the RTOS tick count, then look for the highest priority
task that is ready to run. */
__asm volatile( “bl vTaskIncrementTick” );

#if configUSE_PREEMPTION == 1
__asm volatile( “bl vTaskSwitchContext” );

/* clear timer interrupt. */
        OSTIMER1_CTRL |= 0x00000008;

/* Restore the context of the new task. */

From my IRQ_Handler and program execution never returns back to IRQ_Handler,  instead it eventually enters again the IRQ_Handler from the beggining.  This eventually causes the stack corruption.

void IRQ_Handler(void) __attribute__((interrupt (“IRQ”)));

void IRQ_Handler(void)

       __asm volatile( “bl vTickISR” );


If I leave out the Call to vTickIsr and replace it with nop’s the code execution completes the IRQ_Handler and returns PC to the previous location before exception happened.

So, my question is can I call vTickIsr from my IRQ_Handler?  The ARM7 sample project seems to convey that,  however now I am questioning this.

Can some one shed some light on this?


rtel wrote on Thursday, November 15, 2012:

Answered in your other post.