Port of FreeRTOS of SAMV71 board to Atmel Studio...

jppoulin1967 wrote on Wednesday, April 22, 2015:

Hello FreeRTOS gurus!

There is a very nice port of FreeRTOS on the SAMV71 board found here but it only supports the Keil and IAR IDEs…

Has anyone made this port run on Atmel Studio which provides (awesome) support for this chip?

What are my options?

Thank you!

Jean-Pierre

rtel wrote on Wednesday, April 22, 2015:

Hi Jean-Pierre,

There wasn’t the necessary GCC support when the Cortex-M7 ports were created (which was some months before release), so there is not yet an Atmel Studio demo. There is however a GCC port for the Cortex-M7, so you can create your own project. I believe it is the r0p1 port that is required for current parts:

https://sourceforge.net/p/freertos/code/HEAD/tree/trunk/FreeRTOS/Source/portable/GCC/ARM_CM7/

As there is not (yet) a pre-configured project, the following links may also be helpful:
http://www.freertos.org/Creating-a-new-FreeRTOS-project.html
http://www.freertos.org/porting-a-freertos-demo-to-different-hardware.html

Regards.

jppoulin1967 wrote on Thursday, April 23, 2015:

Hi and thanks for that quick and useful response.

I’ll investigate FreeRTOS running on SAM4S in Atmel Studio and FreeRTOS running on SAM7x on Keil… hopefully the ‘intersection point’ can be figured out and I can get something running! :slight_smile:

Jean-Pierre

jppoulin1967 wrote on Thursday, May 07, 2015:

If this helps anyone you can get FreeRTOS working on V71 board in Atmel Studio / GCC by selecting the Cortex-M3 port of FreeRTOS instead of Cortex-M7 like the chip (GCC will choke on the floating point hardware instructions… can’t get Atmel Studio to build for floating point with their toolchain for their chip!)

rtel wrote on Friday, May 08, 2015:

Thanks for the information…although the code will build, due to an errata in the early devices, you should then switch the code from the FreeRTOS/Source/portable/GCC/ARM_CM3 directory with that from the directory shown on the link above (which is also in the latest FreeRTOS .zip file download) (https://sourceforge.net/p/freertos/code/HEAD/tree/trunk/FreeRTOS/Source/portable/GCC/ARM_CM7 ).

Regards.

jppoulin1967 wrote on Friday, May 08, 2015:

Hi and thanks for info. However the Cortex-M7 GCC port you referred to is the first one I tried to build but like I said above the GCC compiler as configured by Atmel studio is not able to compile the floating point assembler instructions in your Cortex-M7 port!

(I think its a problem of Atmel Studio specifying the wrong GCC assembler arguments so that its assembler would choke on your port)

In our case the non-floating point port of FreeRTOS is better because FreeRTOS won’t have to swap the 32 floating point register at every task switch decreasing its performance (we don’t really need hardware floating point on this chip and would rather have better FreeRTOS performance)

I have FreeRTOS on Atmel Studio / GCC going through its entire test suite and showing the results on the (awesome) FreeRTOS+Trace for the V71 board! I think I’m home free! :slight_smile:

rtel wrote on Friday, May 08, 2015:

Hi and thanks for info. However the Cortex-M7 GCC port you referred
to is the first one I tried to build but like I said above the GCC
compiler as configured by Atmel studio is not able to compile the
floating point assembler instructions in your Cortex-M7 port!

You can modify the command line options by viewing the project options
in Atmel Studio - for example I normally removed the elaborate set of -W
options and replace them with a simple -Wall -Wextra to get a clean
build…

(I think its a problem of Atmel Studio specifying the wrong GCC
assembler arguments so that its assembler would choke on your port)

…so therefore you can add the correct FPU options to the command line.

In our case the non-floating point port of FreeRTOS is better because
FreeRTOS won’t have to swap the 32 floating point register at every
task switch decreasing its performance

FreeRTOS will not save FPU registers for a task that has not used any
FPU instructions - so the performance difference will be as close to
zero as can be (just a couple of extra instructions per task switch if
the task being switched has not used the floating point unit).

I have FreeRTOS on Atmel Studio / GCC going through its entire test
suite and showing the results on the (awesome) FreeRTOS+Trace for the
V71 board! I think I’m home free! :slight_smile:

Not quite if you are using the M3 port as that does not account for the
errata in the chip so at some point, when all the ducks line up at the
same time, at an apparently random time too - it will crash. Hence we
provide a special port to account for the errata so that doesn’t happen.

Regards.

jppoulin1967 wrote on Saturday, May 09, 2015:

Thank you very much for this advice and for taking the time. I will try what you say to see if I can override -mcpu to some settings the GCC compiler included in Atmel studio can understand. (Keil uses a Cortex-M7-fp variant and I wonder if GCC can accept same -mcpu setting… will research and report)

As per your warning I might be seeing what you’re saying right now in my work… While FreeRTOS completes its (very impressive) test suite without error, I get a horribly crash trying to implement my first IRQ queue into a FreeRTOS task… in other words crossing the domain between IRQs and FreeRTOS appears broken in my build… and finding why could be very, very tough.

Quick question for FreeRTOS on Cortex-M devices… does one always invoke the ‘FromISR()’ functions in ISRs regardless of their NVIC priorities? (Had to set a USB IRQ priority much lower to FreeRTOS could accept in its ‘FromISR()’ functions but it still crashes.

richard_damon wrote on Saturday, May 09, 2015:

Unless some function specifically says otherwise (not sure if any do), Interrupt routines should only call the ___FromISR routines, and tasks shouldn’t call these routines, but the version without FromISR in the name.

There are documented limitations on the configuration of the interrupt levels for them to be able to properly call these routines (mainly that there is a interrupt level that below this you can call the API functions, and above this you can not, and these higher interrupt level functions are less impacted by FreeRTOS critical sections), and each port describes how to write an ISR function to work with FreeRTOS.

jppoulin1967 wrote on Saturday, May 09, 2015:

Hi Richard, eureka! I was able to compile your Cortex-M7 port in Atmel Studio / GCC by adding the following arguments in Project Options -> Toolchain -> ARM/GNU C Compiler -> Miscellaneous -> Other flags = “-mfpu=fpv4-sp-d16 -mfloat-abi=softfp” (-mcpu options still at the ‘cortex-m7’ option (I can’t change it in GUI anyways)

However checking on V71 datasheet, their FPU follows the “VFPv5” architecture but I could not find it listed in GCC options at https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

However I tried the above options from the post at http://www.freertos.org/FreeRTOS_Support_Forum_Archive/October_2011/freertos_STM32F4_with_FPU_4761747.html and I’ve been able to build and my IRQ now appears to pass its queue item into FreeRTOS without anything crashing… yet! (Things appear OK in the awesome FreeRTOS+Trace but who knows when I connect all the IRQs I need?)

At this point I don’t know yet if my -mfpu is the right / best choice for this chip or if the -mfloat-abi=softfp is required or set to the best option… Hopefully Atmel will see this message and properly enable floating-point compiler support for their new V71 chip!

Jean-Pierre

P.S. Thanks for the timely help! Was just about to give up after two days of bumping head against monitor!

jppoulin1967 wrote on Sunday, May 10, 2015:

Edit: by testing a bit more I’ve been able to get the Cortex-M7 to work same as above only with the “-mfloat-abi=softfp” arguments (without -mfpu=fpv4-sp-d16). Presumably removing the -mfpu should be safer as hopefully the compiler will choose the best FPU ABI for the V71 chip.

rtel wrote on Sunday, May 10, 2015:

Does that actually use FPU instructions, or just FPU emulation libraries?

Looking at the Atmel Studio project provided for the V71 chip on the
Atmel website - it looks like they just use -mcpu=cortex-m7 and that’s it.

Regards.

jppoulin1967 wrote on Sunday, May 10, 2015:

Yes, their entire sample codebase is setup that way. To my knowledge there isn’t a sample that is setup to use their floating point hardware on their Atmel Studio… a curious omission to not make that part of the chip shine.

Keil samples appear properly setup to compile with their floating point hardware so are able to compile out-of-the-box your Cortex-M7 port.

sjabse wrote on Tuesday, June 02, 2015:

Can you elaborate on how to get FreeRTOS to build for Atmel SAMV71 using the Atmel Studio and GCC ?

rtel wrote on Tuesday, June 02, 2015:

You will find an Atmel Studio package on:
http://www.atmel.com/tools/samv71-samv70-same70-sams70-software-package.aspx

The package does not include FreeRTOS, but provides a project to which
FreeRTOS can be added.
http://www.freertos.org/Creating-a-new-FreeRTOS-project.html
http://www.freertos.org/porting-a-freertos-demo-to-different-hardware.html

Regards.

jppoulin1967 wrote on Thursday, June 04, 2015:

Hi Stuart, to get FreeRTOS to work on SAMV71 board follow the steps below:

  1. Start with a Atmel sample that is closest to the desired functionality.
  2. Insert the FreeRTOS files into the sample project.
  3. Configure FreeRTOS to use the Cortex M7 port files.
  4. In Options / Toolchain / ARM-GNU C Compiler / Miscellaneous set ‘Other flags’ to “-std=gnu99 -mfloat-abi=softfp”. This is critical for the GCC assembler to compile the assembly files with the floating point assembler instructions.
  5. The project should compile and link. I’ve also inserted the FreeRTOS test suite and FreeRTOS+Trace and everything runs with perfect stability. (I haven’t tested if floating point tasks are safely pre-empted yet and I hope they are!)

Good luck and please email me at JeanPierrePoulin AT gmail DOT com if you have enhancements / news on getting the fabulous FreeRTOS to work better on this very impressive chip!

Jean-Pierre

Edit: I believe Atmel should change all its samples to insert the ‘mfloat-abi=softabi’ string into compiler settings. Atmel: is this the best GCC compiler flag to enable floating point compilation on this chip with GCC?

rtel wrote on Thursday, June 04, 2015:

Hi guys, I too have started to create an Atmel Studio demo, although I’m not sure when it will be ready. It will basically replicate the existing IAR and Keil demos.

I would be grateful if you could keep conversation regarding any port/demo work on the forum rather than using direct email.

As an aside, I edited your email address to ensure it is still human readable but not so easily spam bot readable.

Regards.

jppoulin1967 wrote on Monday, June 15, 2015:

Awesome. Let me know how you get things working and of any improvements. :slight_smile:

rtel wrote on Tuesday, June 16, 2015:

I have updated the web page to include information on the Atmel Studio project. A link to the source code is provided in the ‘preamble’ at the top. It is already checked into the public SVN repository so is guaranteed to be included in the next release

http://www.freertos.org/Atmel_SAMV7_Cortex-M7_RTOS_Demo.html

jppoulin1967 wrote on Tuesday, June 16, 2015:

Awesome news!

Is the sample demo for Atmel Studio on the SAMV71 different in any way from the approach I listed above?