New at91SAM3U port: Question on linker stubs.

dcomer wrote on Saturday, 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

dcomer wrote on Saturday, 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

davedoors wrote on Monday, 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?

dcomer wrote on Tuesday, June 01, 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

dcomer wrote on Wednesday, June 02, 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… :slight_smile:

Dave

davedoors wrote on Wednesday, June 02, 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.

dcomer wrote on Thursday, June 03, 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