FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [May 2010 Threads] New at91SAM3U port: Question on linker stubs.Posted by David Comer on May 29, 2010 I am attempting to port FreeRTOS to the at91SAM3U-EK board using the Rowley CrossWorks IDE. I am in the process of defining assembly code for the port specific MACROS.
I have one issue I wonder if someone can help me with. When I run the port (the port is not working but compiles) and investigate via the debugger stepping into port.c, function vPortEnterCritical(), and further stepping into portDISABLE_INTERRUPTS(), I find myself at what appears to be a linker stub called "__vPortSetInterruptMask_from_thumb". I've insured that my portmacro.h file is indeed reference, and have even taken the radical step of deleting all other ports (withing the #ifdef/#endif) for portmacro.h. However, for some reason the compiler insists on insering __vPortSetInterruptMask_from_thumb for the macro.
Has anyone a clue where I should look for the root cause? It is probably a compiler switch, as I do see stubs are options that can be eliminated. However, the use of the switches is not clear to me so I thought I'd see if this has been solved already.
Thanks in advance,
Dave
RE: New at91SAM3U port: Question on linker stubs.Posted by David Comer on May 29, 2010 (This is a report of the question with hopefully more readable text. The SourceForge form editor really sucks!)
I am attempting to port FreeRTOS to the at91SAM3U-EK board using the Rowley CrossWorks IDE. I am in the process of defining assembly code for the port specific MACROS.
I have one issue I wonder if someone can help me with. When I run the port (the port is not working but compiles) and investigate via the debugger stepping into port.c, function vPortEnterCritical(), and further stepping into portDISABLE_INTERRUPTS(), I find myself at what appears to be a linker stub called "__vPortSetInterruptMask_from_thumb". I've insured that my portmacro.h file is indeed reference, and have even taken the radical step of deleting all other ports (withing the #ifdef/#endif) for portmacro.h. However, for some reason the compiler insists on insering __vPortSetInterruptMask_from_thumb for the macro.
Has anyone a clue where I should look for the root cause? It is probably a compiler switch, as I do see stubs are options that can be eliminated. However, the use of the switches is not clear to me so I thought I'd see if this has been solved already.
Thanks in advance,
Dave
RE: New at91SAM3U port: Question on linker stubs.Posted by Dave on May 31, 2010 “I am attempting to port FreeRTOS to the at91SAM3U-EK board using the Rowley CrossWorks IDE. I am in the process of defining assembly code for the port specific MACROS. ” That should not be necessary. All the Cortex M3 ports use the same code. So the Atmel Cortex uses the same code as the NXP Cortex which uses the same code as the Luminary Micro cortex. The GCC version of the files are in FreeRTOS\Source\portable\GCC\ARM_CM3. “ find myself at what appears to be a linker stub called "__vPortSetInterruptMask_from_thumb"” I would expect to see something like that on an ARM7, where interworking code is generated to allow THUMB code to be called from ARM code, and the other way around. I would not expect to see it on a Cortex though, where everything is THUMB2 code, but maybe it does the same? “Has anyone a clue where I should look for the root cause? It is probably a compiler switch” I would recommend looking at the compiler switches in one of the other CrossWorks Cortex projects, even if its not an Atmel project. I would expect the needed switches to be the same. Also, have you tried creating a new (non FreeRTOS) project for the Atmel chip in CrossWorks and starting from that? I guess you have the correct chip support packages installed in CrossWorks?
RE: New at91SAM3U port: Question on linker stubs.Posted by David Comer on June 1, 2010 Hi Dave,
First thanks for your reply. Let me answer your last question first; yes. I did so using File->New Projects (new solution) and selected the SAM3U-EK in the boards category. In other words, I the project was create via template.
With respect to your second question, I did see reference to interworking code in the help for "stub" as a key word, and will read that more thoroughly. I think you instincts on THUMB2 verses THUMB are probably the clue to look for the correct switch.
Finally, with respect to your first comment, one of the reasons I was didn't use the NXP or Luminary example (which I have in the past with good results) is that I'm learning more about CrossWorks CMSIS implimentation. CrossWorks seems to be less complete (actually it's probably more accurate for me to say less straight forward) than IAR or Keil and I'm ramping up the learning curve on CrossWorks. Just have to get used to the IDE and where to find things. I have a SAM7X-EK on order and may work back towards the SAM3U as I resolve these issues and get more confortable with CrossWorks.
Coming from the PIC/PIC32 to the ARM world is a learning curve. In the end I think I will discover the ARM is much more powerful.
Dave
RE: New at91SAM3U port: Question on linker stubs.Posted by David Comer on June 2, 2010 DaveDoors,
Well, I received a reply back from Rowley support to the following: "try setting the "Code Generation Options > ARM/Thumb Interworking" to "No". " I think this is correct and pretty much is what you suggested (compiler switch). The reason I said I think and is that I unfortunately clobbered the project by copying it to a new directory.
So, I start afresh with your suggestion that I use one of the other examples (I choose the CORTEX_LM3S811_GCC as a starting point (since I am familiar with that product) and have the project compiling and loading but ending up in the default SVC_Handler when the call to vPortStartFirstTask (an inline assembly routine is called). It's getting late so I will take that up next debugging session. I suspect that the NVIC on the SAM3U is not set up correctly; that or the interrupts are still enabled. Should be a quick check of the registers. If you have any advice, I'm all ears... :)
Dave
RE: New at91SAM3U port: Question on linker stubs.Posted by Dave on June 2, 2010 Look in FreeRTOS\Demo\CORTEX_LM3S811_GCC\init\startup.c where the vector table is defined. Note the SVCall handler, PendSV handler and SysTick handler are all populated with FreeRTOS functions. You have to populate your vector table with the same three functions.
Is the forum all screwy for anybody else at the moment? The words just go off the edge of the screen.
RE: New at91SAM3U port: Question on linker stubs.Posted by David Comer on June 3, 2010 DaveDoors,
Duh! Yeah, I was really tired when I posted. Then went back and read through the assembly code that starts the first task and realized that the last instruction is a SVC call (starting the first task in the handler). I then realized I am using the CrossWorks startup code; which isn't bad, just need to impliment the interrupts vectors. I may need to deal with the startup code later but haven't compared to another port just yet. I will report on my progress. Thanks for the reply.
BTW, It I type straight into the forum editor, the lines do not break as expected. I have to type into notepad and copy into the edtior window.
Dave
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|