Spansion SK-FM3-100PMC MB9BF506 starter kit board,
a project is also provided for the SK-FM3-64PMC1 starter kit
This page documents a FreeRTOS ARM Cortex-M3 demo application that targets a Spansion
FM3 microcontroller.
IAR and Keil projects are provided that are already pre-configured to run on both the
SK-FM3-100PMC and
SK-FM3-64PMC1
starter kit evaluation boards. The evaluation boards are fitted with a
MB9BF506N
and a MB9AF314 microcontroller respectively.
Note: If this project fails to build then it is likely the version of IAR Embedded Workbench being used is too old. If this is the case, then it is also likely that the project file has been (silently) corrupted and will need to be restored to its original state before it can be built even with an updated IAR version.
See also the FAQ My application does not run, what could be wrong?
The table below provides information on locating the relevant FM3 projects within the official FreeRTOS download:
| Compiler | Target | Project name | Project file location in the FreeRTOS source tree |
| IAR | MB9B500 | RTOSDemo_IAR.eww | FreeRTOS/Demo/CORTEX_MB9B500_IAR_Keil |
| IAR | MB9A300 | RTOSDemo_IAR.eww | FreeRTOS/Demo/CORTEX_MB9A310_IAR_Keil |
| ARM/Keil | MB9B500 | RTOSDemo_Keil.uvproj | FreeRTOS/Demo/CORTEX_MB9B500_IAR_Keil |
| ARM/Keil | MB9A300 | RTOSDemo_Keil.uvproj | FreeRTOS/Demo/CORTEX_MB9A310_IAR_Keil |
| Build configuration | Description |
| Blinky |
This is a very simple configuration. It creates two tasks,
one software timer, and also uses a button interrupt.
The two tasks communicate via a queue, with the receiving task toggling one of the seven segment display LEDs each time a value is received. The "Blinky demo functionality" section of this documentation page highlights the LED used. Pressing user button SW2 generates an interrupt, the service routine for which resets a software timer before turning an LED on. The software timer has a five second period, and when the five seconds expire, the timer callback function turns the LED off again. Therefore, pressing SW2 will turn the LED on, and the LED will remain on until a full five seconds pass without the button being pressed again. The Blinky build configuration uses the main-blinky.c source file. The other two build configurations use the main-full.c source file.
|
| Full |
This is a comprehensive configuration that creates lots of tasks,
queues, semaphores (of various types) and software timers.
The Full configuration creates the same tasks and timers that are created by the Blinky build configuration. In addition to these, the Full configuration also creates a lot of tasks from the set of standard demo 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. The Full build configuration creates yet more timers that are neither part of the Blinky configuration, or the set of standard demo tasks. These additional tasks are described briefly below this table. In total, the full configuration creates approximately 45 tasks! Use the blinky build configuration if a simpler demo is required.
|
| Full_with_optimisation |
The functionality of the Full_with_optimisation configuration
is identical to that of the Full configuration. The compiler
optimisation setting is the only difference between the two.
Full uses no optimisation, while Full_with_optimisation uses high
optimisation.
|
Software timers that are created by both Full build configurations, that are
not part of either the Blinky demo, or the standard demo tasks, include:
Each time the check timer expires, its associated callback function queries the status of all the running standard demo tasks. If a status is returned as 'failed', then the period of the Check timer is shortened to 500ms, from its original setting of 3 seconds.
The check timer callback toggles an LED within the seven segment display each time it executes. The "Blinky demo functionality" and Full demo functionality sections of this documentation page highlight the LEDs used. If the LED toggles every three seconds, then no errors have been reported. If the LED toggles every 500ms, then at least one standard demo task has reported an error. The name of the standard demo task that reported the error is logged in the pcStatusMessage variable, which is defined in main-full.c.
This controls the display of an incrementing number on one of the two seven segment displays.
Note that the UART driver in this demo uses queues to send each character into an interrupt service routine, and out of an interrupt service routine, individually. This is done to demonstrate queues being used in an interrupt, and to deliberately load the system to test the FreeRTOS port. It is not meant to be an example of an efficient driver implementation. An efficient implementation should use FIFOs or DMA if available, and only use FreeRTOS API functions when enough data has been received to warrant a task being unblocked to process the data.
Visible blinky demo functionality
When the "blinky" build configuration is executing correctly:
Visible full demo functionality
Only a few of the many tasks and timers that are created by the full demo have externally observable behaviour. When the "full" build configurations are executing correctly, the following behaviour will be observed:
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.
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 FM3 microcontrollers 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.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
This demo project provides examples of FreeRTOS interrupt service routines - namely INT0_7_Handler() defined in main-full.c and main-blinky.c, and the two UART interrupt handlers MFS0RX_IRQHandler() and MFS0TX_IRQHandler() defined in serial.c.
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 configuration constant.