STMicroelectronics STM32F103 Cortex M3 Demo
[RTOS Ports]
This page describes the FreeRTOS.org demo application for the STMicroelectronics STM32 Cortex-M3 microcontroller. The demo uses the IAR Embedded Workbench
development tools for ARM, and is preconfigured to run on the STM32 evaluation board from ST (instructions are provided should you wish to use an alternative development board).
The evaluation board is fitted with an STM32F103VB microcontroller that
contains 128KBytes of on board flash and 20KBytes of on board RAM. The STM32F103VB also includes both USB and CANbus peripherals.
Note: The V4.3.0 version of the IAR Cortex M3 port introduced the 'configKERNEL_INTERRUPT_PRIORITY' configuration parameter. This parameter permits the interrupt
priority used by the kernel to be configured such that the kernel activity will never delay a higher priority interrupt. See the Configuration and Usage
section of this page for more information.
From FreeRTOS.org V4.7.1 all IAR projects for ARM devices are saved using the IAR Embedded Workbench V5.x format and will not open from V4.x versions.
FreeRTOS.org V4.7.0 and earlier are still available from SourceForge and can be used with Embedded Workbench V4.x.
Upgrading to FreeRTOS.org V4.8.0: Prior to V4.8.0 the FreeRTOS.org kernel did not make use of the SVCall interrupt. From V4.8.0 onwards it does.
Therefore, to upgrade an older project to the V4.8.0 standard, a small edit to the startup code is required. To do this, simply install
vPortSVCHandler() in the SVCall position within the interrupt vector table (contained in the startup source file). The demo projects included in the
FreeRTOS.org download have already been updated so these can be used as an example.
IMPORTANT! Notes on using the STM32 Cortex-M3 Demo
Please read all the following points before using this RTOS port.
- Source Code Organisation
- The Demo Application
- RTOS Configuration and Usage Details
See also the FAQ My application does not run, what could be wrong?
Source Code Organisation
The FreeRTOS.org download includes the source code for all the FreeRTOS.org ports and therefore contains many more files than are required for this demo.
See the Source Code Organization section for a description of the
downloaded files and information on creating a new project.
The IAR workspace file for the STM32F103 demo is called RTOSDemo.eww and is located in the FreeRTOS/Demo/CORTEX_STM32F103_IAR directory.
The Demo Application
Demo application hardware setup
The demo application includes an interrupt driven UART test where one task transmits characters that are then received by another task. For correct
operation of this functionality a loopback connector must be fitted to the UART00 connector of the STM32 evaluation board (pins 2 and 3 must be
connected together on the 9Way connector).
The demo application uses the LEDs and display built onto the prototyping board so no other hardware setup is required.
A J-Link USB JTAG interface is used to interface the host PC with the target.
Building and running the demo application
- Open the FreeRTOS/Demo/CORTEX_STM32F103_IAR/RTOSDemo.eww project from within the Embedded Workbench IDE.
- Select 'Rebuild All' from the IDE 'Project' menu. The project should build with no errors or warnings.
- Select 'Debug' from the IDE 'Project' menu. The microcontroller flash memory will be programmed with the newly built binary and the debugger will break on
the entry to main().
The project includes a bitmap that is built into the binary. This increases the binary size and at some optimisation levels will take the build size above the
32K limit of the Embedded Workbench Kickstart edition. If this becomes an issue then the code size can be reduced by excluding the bitmap from the
build (by removing the pcBitmap array from lcd_message.h, and commenting out the call to LCD_DrawMonoPict() within the same file).
Functionality
The demo application creates 24 persistent tasks, and periodically dynamically creates and destroys another 4. These tasks consist
predominantly of the standard demo application tasks (see the demo application section for details
of the individual tasks).
The following tasks and tests are created in addition to the standard demo tasks:
- High priority interrupt test
A high frequency periodic interrupt is generated
using a free running timer to demonstrate the use of the
'configKERNEL_INTERRUPT_PRIORITY' configuration constant. The interrupt
service routine measures the number of processor clocks that occur between
each interrupt - and in so doing measures the jitter in the interrupt timing.
The maximum measured jitter time is latched in the ulMaxJitter variable, and
displayed on the LCD display by the 'Check' task as described below. The
fast interrupt is configured and handled in the timertest.c source file. This
demonstrates how the kernel can be configured so as to have no impact on higher
priority interrupt processing.
The Cortex-M3 core has the ability to hasten the entry into an interrupt service routine
(and therefore reduce latency) by up to 8 cycles should a high priority interrupt occur
while a lower priority interrupt is already being serviced. The measured jitter time should
therefore be no more than 8 clock cycles.
- LCD task
The LCD task is a 'gatekeeper' task. It is the only task that
is permitted to access the display directly. Other tasks wishing to write a
message to the LCD send the message on a queue to the LCD task instead of
accessing the LCD themselves. The LCD task just blocks on the queue waiting
for messages - waking and displaying the messages as they arrive.
- Check task
This only executes every five seconds but has the highest
priority so is guaranteed to get processor time. Its main function is to
check that all the standard demo tasks are still operational. Should any
unexpected behaviour within a demo task be discovered the 'check' task will
write an error to the LCD (via the LCD task) (this mechanism can be tested by
removing the loopback connector on UART0, and in so doing deliberately generating
an error). If all the demo tasks are
executing with their expected behaviour then the check task writes PASS
along with the max jitter time to the LCD (again via the LCD task), as
described above.
When executing correctly the demo application will behave as follows:
- LEDs LED1, LED2 and LED3 are under control of the 'flash' tasks. Each will flash at a constant frequency, with LED1 being
the fastest and LED3 being the slowest.
- LED4 is under controlled by the the standard ComTest Tx task. LED4 will toggle each time the ComTest Tx task transmits a
character over the RS232 port.
- The 'check' task will write "PASS" and the jitter time in nanoseconds to the display every 5 seconds.
RTOS Port specific configuration
Configuration items specific to these demos are contained in FreeRTOS/Demo/CORTEX_STM32F103_IAR/FreeRTOSConfig.h. The
constants defined in this file can be edited to suit your application. In particular -
- configTICK_RATE_HZ
This sets the frequency of the RTOS tick. The supplied value of 1000Hz is useful for
testing the kernel functionality but is faster than most applications require. Lowering this value will improve efficiency.
- configKERNEL_INTERRUPT_PRIORITY
This sets the interrupt priority used by the kernel.
The kernel should use a low interrupt priority (high numeric value), allowing higher priority interrupts to be unaffected by the
kernel entering critical sections. Instead of critical sections globally disabling interrupts, they only disable interrupts that
are below the kernel interrupt priority.
This permits very flexible interrupt handling:
- At the kernel priority level interrupt handling 'tasks' can be written and prioritised
as per any other task in the system. These are tasks that are woken by an interrupt. The interrupt service routine (ISR) itself should be written to
be as short as it possibly can be - it just grabs the data then wakes the high priority handler task. The ISR then returns directly into the
woken handler task - so interrupt processing is contiguous in time just as if it were all done in the ISR itself. The benefit of this is that
all interrupts remain enabled in the handler task.
-
ISR's running above the kernel priority are never masked out by the kernel itself, so their responsiveness is not effected by the kernel functionality.
However, such ISR's cannot use the FreeRTOS.org API functions. The fast timer interrupt test within the demo demonstrates this behaviour.
Each port #defines 'portBASE_TYPE' to equal the most efficient data type for that processor. This port defines
portBASE_TYPE to be of type long.
Note that vPortEndScheduler() has not been implemented.
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 ISR.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
Switching between the pre-emptive and co-operative real time kernels
Set the definition configUSE_PREEMPTION within FreeRTOS/Demo/CORTEX_STM32F103_IAR/FreeRTOSConfig.h to 1 to use pre-emption or 0
to use co-operative.
Compiler options
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.
Memory allocation
Source/Portable/MemMang/heap_2.c is included in the ARM Cortex-M3 demo application project to provide the memory
allocation required by the real time kernel.
Please refer to the Memory Management section of the API documentation for
full information.
Copyright (C) 2003 - 2008 Richard Barry
Any and all data, files, source code, html content and documentation included in the FreeRTOS.org distribution or available on this site are the exclusive property of Richard Barry.
See the files license.txt (included in the distribution) and this
copyright notice for more information. FreeRTOS
TM and FreeRTOS.org
TM are trade marks of Richard Barry.
