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

Stack Problem - Lattice MICO32 Port

Posted by fkln on December 30, 2007
I'm working on a FreeRTOS port for Lattice MICO32 Processor (FPGA).

As a sample, I take the documentation about the Coldfire Implementation.

My actual problem is in Example Program 2 which prints out the two different Task-ID's.
The first two printfs are correct, the remaining printfs are wrong, because the Task-ID's have changed,
probable because the Context Switching is wrong.


I am wondering about the vPortYield Funktion.

void vPortYield( void )
{
portSAVE_CONTEXT();
vTaskSwitchContext();
portRESTORE_CONTEXT();
}

The following code is a disassembly from the final code

void vPortYield( void )
{
// The following 3 lines are automatically generated from the gcc Compiler
addi sp,sp,-4 Decrement Stack
sw (sp+4),ra Store Return Address on Stack
sw (sp+0),sp Store content of Stack on Stack

// macro portSAVE_CONTEXT();
addi sp,sp,-120 Decrement Stack by size of registers which are stored on the stack
sw (sp+116),r1 Store content of first register on Stack
.... Store remaining registers on Stack
sw (sp+4),ra Store Return Address on Stack

and r1,r0,r0 Clear register R1
mvhi r1,hi(pxCurrentTCB) Load High-Halfword of CurrentTCB
ori r1,r1,lo(pxCurrentTCB) Load Low-Halfword of CurrentTCB
lw r1,(r1+0) Load Pointer from CurrentTCB
sw (r1+0), sp Store actual StackPointer into current CurrentTCB - TopOfStack

calli vTaskSwitchContext Call vTaskSwitchContext() Function

// macro portRESTORE_CONTEXT();
and sp,r0,r0 Clear StackPointer
mvhi sp,hi(pxCurrentTCB) Load High-Halfword of CurrentTCB
ori sp,sp,lo(pxCurrentTCB) Load Low-Halfword of CurrentTCB
lw sp,(sp+0) Load Pointer to CurrentTCB
lw sp,(sp+0) Load content from CurrentTCB - TopOfStack

lw ra,(sp+4) Load Return Address from Stack
...... Load remaining registers on Stack
lw r1,(sp+116)Load content of first register from Stack

// The following 3 lines are automatically generated from the gcc Compiler
lw ra,(sp+4) Load Return Address from Stack
addi sp,sp,4 Increment Stack
ret Return from Subroutine
}


Any idea what is going wrong ?

Anyway, I have also tried the use the "naked" attribute, but the code for this fuction is always the same.

Thanks,

Klaus





RE: Stack Problem - Lattice MICO32 Port

Posted by Richard on December 30, 2007
I don't know anything about this processor unfortunately, but have a thought about the compiler generated code. It will be ok to let the compiler insert these instructions (not using the naked attribute - which is not supported by GCC for all targets) ONLY if the code is exactly the same AT EVERY POINT that a context switch occurred.

For example, consider what happens when a task yields. Its gets swapped out by a call to YIELD - which modifies the stack by the compiler generated code, then saves the context. What would then happen if the same task was swapped back in again from an interrupt? Would the stack be unwound in exactly the same way - or would exiting the interrupt leave the stack in an unexpected position before the YIELD function was exited?

Whether this would work or not depends on the processor and compiler behaviour. If it does not work, and the naked attribute is not supported, then you might have to write an assembly code wrapper for the YIELD function.

Regards.

RE: Stack Problem - Lattice MICO32 Port

Posted by fkln on December 30, 2007
Thanks for the reply.

If someone is interested into the datasheet, here is a link
http://www.latticesemi.com/documents/doc20890x45.pdf

At the moment, I have no interrupts.

I am wondering why I loose the right values for task1id and task2id
(http://www.freertos.org/coldfire/phase3.html).
Could this really happen or is something with the stack not correct.

Another question belongs to the interrupt handling.
There is only one common vector for all 32 interrupts. All the interrupt handling
(Enable, disable, register Interrupt Service Routine ...) is done by library functions from Lattice.

How should I implement the Interrupt for the Systemtimer Tick ?
Shall I modify the library functions from lattice (complete source code is available) or
shall I redirect the Interrupt vector to a Interrupt handler in FreeRTOS.
In this handler I can check if it is a Systemtimer interrupt or not.
If it is a Systemtimer interrupt I can do the necessary things for FreeRTOS.
If it is not a Systemtimer interrupt, I can jump to the library function from Lattice.

What is the best approach ?

Thanks,

Klaus

RE: Stack Problem - Lattice MICO32 Port

Posted by fkln on January 2, 2008
"I am wondering why I loose the right values for task1id and task2id"
"(http://www.freertos.org/coldfire/phase3.html)."
"Could this really happen or is something with the stack not correct."

-> I have found the problem. At the end of portRESTORE_CONTEXT() I must correct the stack.

Klaus


[ 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