nobody wrote on Monday, July 24, 2006:
Hi,
I am looking to port the FreeRTOS onto the STR9 using the Keil tool. Please advice on where I should start. I have seen the port on the same Micro using IAR tool, should I start on that example?
It is a big task, Please help
rtel wrote on Monday, July 24, 2006:
It should be straight forward. Here are some notes:
+ Create a directory to hold the new port files. This should be something like FreeRTOS/Source/Portable/Keil/STR9.
+ Copy the FreeRTOS/Source/Portable/IAR/STR9 files into this directory.
+ Open FreeRTOS/Source/include/portable.h and add a new line something like:
#ifdef KEIL_STR9
#include "…\…\Source\portable\Keil\STR9\portmacro.h"
#endif
+ Create a new directory to hold the new demo app files. Something like FreeRTOS/Demo/ARM9_STR91X_KEIL. Create a new uVision project targeted at the STR91x and a new main.c file in this directory. Also copy the FreeRTOSConfig.h file from the IAR STR9 demo into this directory.
+ In your new project include the following files:
FreeRTOS/Source/tasks.c
FreeRTOS/Source/list.c
FreeRTOS/Source/queue.c
FreeRTOS/Source/portable/keil/STR9/port.c
FreeRTOS/Source/portable/memmang/heap_2.c
main.c
+ Make sure header files can be located in the following directories
FreeRTOS/Source/include
FreeRTOS/Source/portable/keil/STR9
.
+ Check the startup code that is included in the project. Ensure this includes a stack allocation for IRQ and supervisor modes. You can take the values from the IAR equivalent. In addition ***ENSURE THAT MAIN IS CALLED FROM SUPERVISOR MODE***.
+ Convert the IAR syntax in the files that were copied from the STR9 port layer to Keil format. Code that uses a separate assembly file for IAR can probably be incorporated into inline assembly when using Keil. Use the Keil ARM7 port for examples.
However, the easiest way to do this might to be to take the example interrupt handling mechanism from the IAR code. If you look in the IAR example (function IRQHandler in file FreeRTOS/Demo/ARM9_STR91x_IAR/91x_vect_IAR.s) you will see that IRQ interrupts do not read the interrupt controller directly but first jump to IRQHandler. This saves the task context, then obtains the handler address from the interrupt controller, then calls the interrupt handler just like an ordinary function. This removes the reliance on the compiler specific extensions like __irq keywords, but has the disadvantage of saving the context on every interrupt which might be wasteful.
This part will take a bit of fiddling around, keep checking the Keil ARM7 example.
+ Write a small task along the lines of:
void vATask( void * pvParameters )
{
for( ;; )
{
FlashLED();
vTaskDelay( 250 );
}
}
+ Get it to compiler. Some hassle here no doubt but it should not put up too much of a fight.
+ In your main.c file, setup any hardware necessary (see prvSetupHardware() in the main.c file for the IAR demo). Then create the task just defined, and start the scheduler. You can see examples of this again in the IAR example.
+ If nothing happens, step through the code and see where it goes pair shaped. First place a break point on main() to see if you get through the startup code. Next on where the scheduler is started to see if you get through the hardware init code. Then finally step through the scheduler being started. If there are any problems starting the scheduler report back here where the problem occurs.
Also check out the following link:
http://sourceforge.net/forum/forum.php?thread_id=1537075&forum_id=382005
Regards.
nobody wrote on Tuesday, August 15, 2006:
Hi Richard,
I am looking at the source code of the FreeRTOS.
In the function prvSetupTimerInterrupt (port.c), at the end, I found two line:
VIC0->DVAR =(unsigned portLONG) prvDefaultHandler;
VIC1->DVAR =(unsigned portLONG) prvDefaultHandler;
I tried to look for the prvDefaultHandler, but I couldn’t find it.
Please help thanks you
nobody wrote on Tuesday, August 15, 2006:
Hi Richard,
I am looking at the source code of the FreeRTOS.
In the function prvSetupTimerInterrupt (port.c), at the end, I found two line:
VIC0->DVAR =(unsigned portLONG) prvDefaultHandler;
VIC1->DVAR =(unsigned portLONG) prvDefaultHandler;
I tried to look for the prvDefaultHandler, but I couldn’t find it.
Sorry I forget to mention it’s the port for STR9 with IAR tool.
Please help thanks you
rtel wrote on Tuesday, August 15, 2006:
prvDefaultHandler is the handler for spurious interrupts. It is very important that this is installed.
It is defined at the very bottom of the same file from which you extracted the code. It does not do anything, other than return safely from the interrupt:
static void prvDefaultHandler( void )
{
}
Regards.
nobody wrote on Wednesday, August 16, 2006:
Hi Richard,
Thanks for your response. I think I got it.
VIC0->DVAR =(unsigned portLONG)prvDefaultHandler;
VIC1->DVAR =(unsigned portLONG)prvDefaultHandler;
The lines above have nothing to do with the watchdog interrupt.
Thanks
rtel wrote on Wednesday, August 16, 2006:
Yes,…and no.
They are indirectly related to the watchdog interrupt.
Although they are nothing to do with the configuration of the watchdog interrupt, they are still required to ensure that spurious interrupts originating from the watchdog are handled correctly.
Regards.
nobody wrote on Thursday, August 17, 2006:
Hi Richard,
Thanks for the response. I am still some what unclear. So please help me out.
VIC_Config( WDG_ITLine, VIC_IRQ, 10 );
the above function call is in the function to initialize the watchdog. It calls this function: VIC_ISRVectAddConfig(VIC_Source, VIC_Priority, WDG_IRQHandler). These two functions set up the address for the interrupt service function for the watchdog.
If the watchdog interrupt has the service function already, then why do we need the default handler.
Please help
Thank you so much.
nobody wrote on Thursday, August 17, 2006:
It is something to do with the interaction between the interrupt controller and the ARM core. Sometimes when the watchdog generates an interrupt the core momentarily cannot determine which peripheral cause the interrupt so the default handler is called instead of the watchdog handler.
The default handler can either poll all peripherals to determine which actually caused the interrupt, or it can simply return. When it simply returns the watchdog interrupt has not been cleared, so immediately the watchdog interrupt is re entered, hopefully this time the correct one.
Take a look at http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10414_1.pdf, although this is for a different chip.
nobody wrote on Friday, September 08, 2006:
Hi Richard,
How are you? I am still working on this port, and decided to convert the assembly files to work with Keil/Realview tool set.
The first two lines of the file 91x_vect_IAR.s:
#include "FreeRTOSConfig.h"
#include "ISR_Support.h"
The file ISR_Support.h contain MARCO for portRESTORE_CONTEXT, and portSAVE_CONTEXT; I use
INCLUDE instead of #include because the realview assembler doesn’t know what to do with the #. Do you see any problem with this? Please advice.
Next, FreeRTOSConfig.h file contains #define …
this file need to be preprocess by c compiler, right? This is the one I have problem with.
I also noticed that this file, FreeRTOSConfig.h, is not needed to assemble 91x_vect_IAR.s. Please advice.
Is there a way to include c header that contains #define in an assembly file?
The document from realview saying that it is possible; however when I follow their instruction it doesn’t work at all.
Here is the link I found the information.
http://www.arm.com/support/faqdev/1208.html
I also look in the keil/realview’s assembler manual. It also says that it is possible, but when I follow it doesn’t work.
Please advice
Thank You so much for you help
rtel wrote on Friday, September 08, 2006:
> The file ISR_Support.h contain MARCO for portRESTORE_CONTEXT, and portSAVE_CONTEXT;
> I use
> INCLUDE instead of #include because the realview assembler doesn’t know what
> to do with the #. Do you see any problem with this? Please advice.
The include file is not really needed in Keil. The IAR port needs assembly wrappers for ISR’s due to the limited functionality of its inline assembler. The ISR_Support.h file is included in the port files, and also in the assembly file wrappers (take a look at serialISR.s79).
If you look at the Keil demo portmacro.h file you will see that there are macros called portSAVE_CONTEXT(), portRESTORE_CONTEXT() and portENTER_SWITCHING_ISR() and portEXIT_SWITCHING_ISR() that all use the inline assembler. Then take a look at the function vUART_ISR() in the serialISR.c file of the Keil demo and you will see that the use of the keword _task along with these macros makes the include helper file obsolete. That is not to say you could not copy the technique used in the ISR port, but personally I prefer to keep everything in C, and the Keil compiler functionality allows you to avoid the asm wrapper files.
> Next, FreeRTOSConfig.h file contains #define …
> this file need to be preprocess by c compiler, right? This is the one I have
> problem with.
> I also noticed that this file, FreeRTOSConfig.h, is not needed to assemble
> 91x_vect_IAR.s. Please advice.
>
> Is there a way to include c header that contains #define in an assembly file?
> The document from realview saying that it is possible; however when I follow
> their instruction it doesn’t work at all.
> Here is the link I found the information.
> http://www.arm.com/support/faqdev/1208.html
>
> I also look in the keil/realview’s assembler manual. It also says that it is
> possible, but when I follow it doesn’t work.
>
> Please advice
>
> Thank You so much for you help
All the compilers have different requirements and syntax. The Keil compiler is more forgiving than the IAR compiler when it comes to the FreeRTOS.org port layer. I don’t think you have to concern yourself with these matters in trying to convert the IAR code to Keil code - I have done this already for the ARM7, and most of the code is common to the ARM9 port. It might be more productive to base your code on the portmacro.h that already exists for the Keil compiler ARM7 port, or at least use this to see how the assembler is used.
Regards.
jra01 wrote on Monday, September 11, 2006:
I have made a port for the RealView compiler for the ARM7 (SAM7S). It is available (at least the changed files) at:
http://www.ktc.se/aspx/files/SAM7_Keil_RV.zip
I remember I had problems with very restricted use of inline assembly, forcing me to use more explicit assembly files than for the CARM compiler. I think I took a lot from the IAR port, wich had a more similar approach.
For Richard:
I get the impression you don’t realize that Keil are switching to the compiler from ARM, RealView, since they were bougth by ARM. It is a completely different compiler, that supports c++ etc. Therefor we need completely new Keil ports now.
My personal experience is that Keil still have some work to do to make the IDE, especially the debuger, to work good with their new compiler, but that the compiler itself is better than the "CARM".
Regards
Jokke
rtel wrote on Monday, September 11, 2006:
> get the impression you don’t realize that Keil
>are switching to the compiler from ARM,
>RealView, since they were bougth by ARM. It is a
>completely different compiler, that supports c++
>etc. Therefor we need completely new Keil ports
>now.
When I got a uVision upgrade to write the Cortex port it came with the RVDS compiler. When I tested the original Keil ARM7 ports they still seemed to compiler and run with no problems, so I assumed compatibility - although maybe they ship the IDE with both compiler version?
I tend to use Keil, ARM and RVDS interchangeably now to cause maximum confusion.
Regards.
jra01 wrote on Monday, September 11, 2006:
Yes, they ship with both compilers, and you have to reconfigure the project to use RealView, otherwise you will stay with CARM. Under "extensions books and environment" you do this set-up.
Regards
Jokke
nobody wrote on Wednesday, September 27, 2006:
Hi Richard,
I did get it compiled however when I create tasks and start scheduler, I got data abort exception.
I did test the RTOS tick works ok.
Do you have any idea where I should look.
Thanks
nobody wrote on Thursday, September 28, 2006:
Hi Richard,
I got it compiled, but still have some problem.
It got thru the startup and hardware initialize fine, I tested the code without RTOS.
The problem is when I create Task, and start the scheduler, Prefetch exception happens.
To get it start in supervisor mode, I left the stack of the user mode unitialized. Could this be the problem?
Realview disallows to swith from user mode to supervisor mode, I think.
;Enter User Mode and set its Stack Pointer
; MSR CPSR_c, #Mode_USR
; MOV SP, R0
; SUB SL, SP, #USR_Stack_Size
; I comment out the above to keep it start in
; supervisor mode and left the stack of the user
; mode unitialized
; if I leave the above in, the following won’t
; switch it back to the supervisor mode
;
MSR CPSR_c, #Mode_SVC:OR:I_Bit:OR:F_Bit
Please take a look at this,
http://www.keil.com/support/docs/3226.htm
Please help
rtel wrote on Thursday, September 28, 2006:
The processor itself does not permit a switch from user mode to Supervisor mode, rather than the compiler.
You do not need to setup a user mode stack so it is safe to leave this out. You only need to set up (as a minimum depending on your app) a Supervisor stack and an IRQ stack. Tasks use System mode, but their stack is allocated by the kernel when the task is started.
Does the old Keil startup code not compile with the RVDS compiler? It would seem very limiting if the compiler did not allow you to access SPSR at all.
Regards.
nobody wrote on Thursday, September 28, 2006:
Thanks for the response.
Do you have any suggestion on where to look to find the cause of the Prefetch_exception?
nobody wrote on Tuesday, October 17, 2006:
Hi! I’m also looking for Webserver Demo running on Keil Tool on my STR9. Do you have a running Port now and would you like to share it?
It would be great if I don’t have to do this work by myself again. Link?
Thanks, Stefan