Microsemi (formally Actel) SmartFusion A2F200M3F Demo
Using GCC and the SoftConsole Eclipse based IDE
Includes a tiny embedded web server with CGI scripting
[Embedded Ethernet Examples]
SmartFusion A2F-EVAL-KIT Evaluation Kit
This page documents a FreeRTOS ARM Cortex-M3 demo application that targets the Microsemi (formally Actel)
SmartFusion mixed signal FPGA with integrated ARM Cortex-M3 microcontroller.
FreeRTOS includes ARM Cortex-M3 ports for the GCC, Keil and IAR compilers. Demo application
projects targeting the A2F200M3 SmartFusion are provided for the SoftConsole (Eclipse), IAR Embedded Workbench,
and Keil MDK IDEs . This page provides instruction on using the GCC / SoftConsole IDE only.
A separate page provides instructions on using the IAR and Keil IDEs.
The SoftConsole project is configured to run on the
SmartFusion evaluation board.
An example embedded web server implementation is included. This makes use of a modified version of the
tiny uIP TCP/IP stack.
Code-named FreeTCPIP, the modifications to the TCP/IP stack allow a higher
throughput than can be achieved with the original code. Dynamic web pages showing
RTOS, TCP/IP and task run time statistics are
created and served using the standard uIP CGI scripting facility.
uIP was originally written by Adam Dunkels. It is open source, but licensed
separately from FreeRTOS. Users must familiarise themselves with the
uIP licence, which is detailed at the top of each uIP source file.
IMPORTANT! Notes on using the FreeRTOS SoftConsole/Eclipse/GCC SmartFusion Demo Project
Please read all the following points before using this RTOS port.
See also the FAQ My application does not run, what could be wrong?
- Source Code Organisation
- The Demo Application
- RTOS Configuration and Usage Details
Source Code Organisation
The FreeRTOS zip file download contains source code for all the FreeRTOS ports,
and every demo application project.
It therefore contains many more files than are required to build and run the SmartFusion SoftConsole demo. See the
Source Code Organization section for a description
of the downloaded files, and information on creating a new project.
The SoftConsole project file for the SmartFusion A2F200M demo is located in the
FreeRTOS/Demo/CORTEX_A2F200_SoftConsole directory. This is the project
that should be imported into the SoftConsole workspace. The Preparing the Eclipse Project
section below contains important information on setting up the demo project directory,
and importing the demo project into SoftConsole.
Preparing the SoftConsole (Eclipse) project directory
Eclipse projects can be either standard makefile projects, or managed make projects.
The SmartFusion SoftConsole project uses a managed make project. This in turn means that
Option 1 is used in this case. To that end, the directory FreeRTOS/Demo/CORTEX_A2F200_SoftConsole
contains a batch file called CreateProjectDirectoryStructure.bat that
will copy all the required FreeRTOS source files into sub directories inside the
demo project directory.
- All the source files needed to build the project must be located under
the folder/directory that contains the project file itself, or
- That the Eclipse workspace (note workspace, not project) needs to be
configured to locate the files elsewhere on the hard disk.
CreateProjectDirectoryStructure.bat must be executed before the SoftConsole
project is imported into the Eclipse workspace.
CreateProjectDirectoryStructure.bat cannot be
executed from within the SoftConsole Eclipse IDE.
The SmartFusion A2F Demo Application
The SoftConsole project contains three build configurations:
This is a very simple example. It creates two tasks,
one software timer, and also uses a button interrupt.
The two tasks communicate via a queue - the queue send task, and
the queue receive task. The queue receive task toggles an LED
each time it receives a value.
Pressing user button SW1 generates an interrupt, the ISR for the
interrupt resets a software timer before turning an LED on.
The software timer has a five second period, and when the five
seconds has expired, the software timer callback function turns the LED off again.
Therefore, pressing SW1 will turn the LED on, and the LED will
remain on until a full five seconds pass without the button being
The Blinky build configuration uses the
main-blinky.c source file. The other two build configurations use
the main-full.c source file.
This is a comprehensive demo that creates lots of tasks,
queues, semaphores (of various types) and software timers.
The Full build configuration creates the same tasks and timers that are
created by the Blinky build configuration. In addition to these,
the Full build configuration also creates a lot of tasks from the set of
tasks. The standard demo tasks don't perform any particular function.
Their purpose is firstly to test the FreeRTOS port, and secondly to
provide examples of how to use the FreeRTOS API functions.
Further, the Full build configuration creates yet more tasks that are neither
part of the Blinky configuration, or the set of standard demo tasks.
These additional tasks are described briefly below this table.
The functionality of the Full_with_optimisation build configuration
is identical to that of the Full build configuration. Full_with_optimisation
has compiler optimisation set high. Full has compiler optimisation
off. That is the only difference between the two.
Tasks and timers that are created by both the Full and Full_with_optimisation
build configurations, that are not part of either the Blinky demo, or the standard
demo tasks, include:
- A "Check" software timer and callback
Each time the check timer expires, its associated callback function
queries the status of all the running standard demo tasks. If any queried
status is returned as 'failed', then the period of the Check timer is shortened
to 500ms, from its original setting of 3 seconds.
The callback function assigned to the check timer toggles LED D8 each time it executes. Therefore,
if LED D8 is toggling every three seconds, then no errors have been reported.
If LED D8 is toggling every 500ms, then at least one standard demo task has
reported an error. The name of the standard demo task that reported the
error can be viewed using the embedded web server - it is displayed at the
bottom of the "task stats" web page, under the task stats table.
- uIP task
All TCP/IP related processing is contained in the uIP task. The Flash and RAM
footprint of the TCP/IP stack is extremely small compared to other embedded
- OLED task
The OLED task scrolls a message across both of the two OLED rows.
Web server configuration
The demo application includes an embedded web server. The IP address used by the
web server is fixed, and set set by the constants configIP_ADDR0 to
configIP_ADDR3. The definition of these constants can be found near the bottom
of the FreeRTOSConfig.h header file, which is itself located in the same
directory as the SoftConsole project file.
Constants that define the MAC address, and the NET mask, are located in the same
The IP addresses used by the web server running on the SmartFusion device, and
the web browser used to connect to the web server, must be
compatible with each other. To ensure this is the case, make the first three
octets of both IP addresses the same. For example, if the web browser computer
uses IP address 192.168.0.1, then the SmartFusion device can be given any IP
address in the range 192.168.0.2 to 192.168.0.254 - other than any IP addresses
that is already present on the same network.
The MAC address assigned to the SmartFusion device must be unique on the network
to which the device is being connected.
Hardware set up
This section provides instructions on the hardware set up required to
program an application into the ARM Cortex-M3 flash memory. It is assumed that the
SmartFusion FPGA fabric and ACE are already configured correctly, which will be the case if
the configuration has not been changed from that programmed into the device
when the A2F-EVAL-KIT was shipped. However, if the FPGA fabric
or ACE configuration has been altered from that shipped, and you find the demo
application does not execute correctly, then it is recommended to restore the FPGA
fabric and ACE configuration using the .pdb file supplied
with the A2F-EVAL-KIT kit.
Ensure jumper JP7 is set to the "USB PROG" position.
Ensure jumper JP10 is set to the "M3" position.
Connect a USB cable from the port marked "J13" and "USB PROG" (that is the
same connector) on the A2F-EVAL-KIT
board to the computer that is running the SoftConsole IDE. This is
the port through which the ARM Cortex-M3 will be programmed.
Use an Ethernet cable to connect the A2F-EVAL-KIT hardware to a computer
running a standard web browser. This needs to be done either directly,
by using a crossover (point to point) Ethernet cable, or through a
hub/switch, using a standard Ethernet cable. Only the direct connection
option was tested during development of the demo, but both methods
Connect a USB cable from the port marked "J14 USB/UART" to any USB port
that is capable of supplying power. In this demo, J14 is only used as a power
Importing the demo application project into the CCS Eclipse workspace
To import the SmartFusion SoftConsole project into an existing or new Eclipse Workspace:
Select "Import" from the SoftConsole "File" menu. The dialogue box shown below
The dialogue box that appears when "Import" is first clicked
In the next dialogue box, select FreeRTOS/Demo/CORTEX_A2F200_SoftConsole
as the root directory. Then, make sure the RTOSDemo
project is checked in the "Projects" area, and that the Copy Projects Into
Workspace box is not checked, before clicking
the Finish button (see the image below for the correct check box states,
the finish button is not visible in the image).
Make sure that RTOSDemo is checked, and "Copy projects into workspace" is not checked
Building and executing the demo application using SoftConsole tools
- Ensure that CreateProjectDirectoryStructure.bat has been executed,
and that the project has been correctly imported into the Eclipse workspace.
Select the required build configuration.
Select 'Rebuild All' from the IDE 'Project' menu.
Select 'Debug Configurations...' from the IDE 'Run' menu.
In the dialogue box that appears, highlight "Microsemi ARM Cortex-M3 eNVM Target"
in the tree of targets on the left hand side, then click the
"New Launch Configuration" speed button, highlighted in red in the image below.
A new debug configuration will be created that should be named to match
the build configuration being used. In the image below, the "Blinky"
build configuration was being used.
Ensure the correct application file is being used, highlighted in green
in the image below. In this case, because the "Blinky" build configuration
was being used, the correct application file is "Blinky\RTOSDemo".
Click the "Debug" button to commence debugging.
Creating a debug configuration
When executing correctly, the demo application will behave as follows:
Served web Pages
The top of each served page includes a menu with links to every other page.
The RTOS stats page served by the SmartFusion web server
showing status information on each task in the system.
The run time stats page served by the SmartFusion web
server showing the processor utilisation of each task.
The served IO page
The IO page provides a simple interface to permit two LEDs to be turned on and off from a web browser.
It also displays the current raw analogue input reading from the 50K potentiometer that is located
next to the OLED on the evaluation board. Changes are sent to the target board whenever the "Update IO" button is clicked.
Values displayed on the IO page are updated each time the "Update IO" button is clicked, or the served
web page is refreshed.
Other served pages include TCP/IP statistics, and a large JPG image. All the web pages are included in the downloaded
binary image - which can make the binary image appear to be quite large (the jpg file by itself is in excess of 36K).
Cortex-M3 FreeRTOS port specific configuration
Configuration items specific to this demo are contained in FreeRTOS/Demo/CORTEX_A2F200_SoftConsole/FreeRTOSConfig.h.
The constants defined in this file can be edited to suit your application. In particular -
This sets the frequency of the RTOS tick interrupt. The supplied value of 1000Hz is useful for
testing the RTOS kernel functionality but is faster than most applications require. Lowering this value will improve efficiency.
- configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
See the RTOS kernel configuration documentation for full information on these configuration constants.
Attention please!: Remember that ARM Cortex-M3 cores use
numerically low priority numbers to represent HIGH priority interrupts. This
can seem counter-intuitive and is easy to forget! If you wish to assign an
interrupt a low priority do NOT assign it a priority of 0 (or other low numeric
value) as this will result in the interrupt actually having the highest priority
in the system - and therefore potentially make your system crash if this
priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY. Also, do not leave
interrupt priorities unassigned, as by default they will have a priority of 0
and therefore the highest priority possible.
The lowest priority on a ARM Cortex-M3 core is in fact 255 - however different
Cortex-M3 vendors implement a different number of priority bits and supply library
functions that expect priorities to be specified in different ways. For example,
on the A2F the lowest priority you can specify is in fact 15 - this is defined by the constant
configLIBRARY_LOWEST_INTERRUPT_PRIORITY in FreeRTOSConfig.h. The highest priority
that can be assigned is always zero.
It is also recommended to ensure that all four priority bits are assigned as
being premption priority bits, and none as sub priority bits.
Each port #defines 'BaseType_t' to equal the most efficient data type for that
processor. This port defines BaseType_t to be of type long.
Interrupt service routines
Unlike most ports, interrupt service routines that cause a context switch have
no special requirements, and can be written as per the compiler documentation.
The macro portEND_SWITCHING_ISR() can be used to request a context switch from
within an interrupt service routine.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
This demo project provides examples of FreeRTOS interrupt service routines -
namely GPIO8_IRQHandler() defined in main-full.c and main-blinky.c, and the
Ethernet MAC interrupt handler.
Only FreeRTOS API functions that end in "FromISR" can be called from an
interrupt service routine - and then only if the priority of the interrupt
is less than or equal to that set by the configMAX_SYSCALL_INTERRUPT_PRIORITY
Resources used by FreeRTOS
FreeRTOS requires exclusive use of the SysTick and PendSV interrupts. SVC number #0 is also used.
Switching between the pre-emptive and co-operative RTOS kernels
Set the definition configUSE_PREEMPTION within RTOSDemo/FreeRTOSConfig.h to 1 to use pre-emption or 0
to use co-operative. The full demo application may not execute correctly when the co-operative RTOS scheduler is
As with all the ports, it is essential that the correct compiler options are used. The best way to ensure this is to base your
application on the provided demo application files.
Source/Portable/MemMang/heap_2.c is included in the SmartFusion A2F demo application project to provide the memory
allocation required by the RTOS kernel.
Please refer to the Memory Management section of the API documentation for
Note that vPortEndScheduler() has not been implemented.
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.