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

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


[ 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