Three demo applications are provided for the CrossWorks port, two targeted for the DK-LMS102 development board from Luminary Micro, and one targeted at
the low cost CrossFire LM3S102 board from Rowley Associates. The CrossFire LM3S102 connects
directly to the host computer via the built in USB connector and does not require the use of a separate JTAG interface.
Stellaris is a new range of microcontrollers - the first to be commercially available with a Cortex-M3 core. The LM3S102 is a low cost, low pin count device. It has
2KBytes of RAM and 8KBytes of ROM on chip. An ideal candidate to demonstrate the new co-routine functionality included with FreeRTOS V4.0.0.
The CrossWorks Cortex-M3 demos rely on a driver library and makefile which is licensed separately from FreeRTOS. The license conditions are included within the comments at the
top of the library header files located in the Demo/CORTEX_LM3S102_ROWLEY/hw_include directory. A full copy of the license is available in the same directory.
Upgrading to FreeRTOS.org V5.0.3: FreeRTOS.org V5.0.3 introduced the configMAX_SYSCALL_INTERRUPT_PRIORITY configuration option to the Cortex M3 port. See
the kernel configuration documentation for full information on this feature.
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.
The CrossWorks solution (workspace) for the Luminary Micro port is located in the FreeRTOS/Demo/CORTEX_LM3S102_ROWLEY directory.
The demo application includes an interrupt driven UART test where a co-routine transmits characters that are then received by a task. For correct operation
of this functionality a loopback connector must be fitted to the SER0 connector of the DK-LMS102 prototyping board (pins 2 and 3
must be connected together on the 9Way connector).
The demo application uses the LEDs built into the prototyping board so no other hardware setup is required.
A CrossConnect JTAG interface is used to interface the host PC with the target board.
The Demo-2 application has similar functionality but tests different features of the RTOS port.
To build the application.
Also note configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY.
See the kernel configuration documentation for full information on these configuration constants.
Attention please!: Remember that Cortex M3 cores use numerically low priority numbers to represent HIGH
priority interrupts, which 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 can 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.
The lowest priority on a 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. Use the supplied examples as a reference.
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.
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. This mechanism is demonstrated by the UART ISR defined within
main.c (see the function vUART_ISR()). Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
There are currently four FreeRTOS ports for Luminary Micro Stellaris Cortex based embedded microcontrollers - one that uses the Sourcery G++ (GCC) tools,
one that uses the ARM Keil tools, another for the IAR tools, and the port presented on this page which uses
Rowley CrossWorks.
IMPORTANT! Notes on using the ARM Cortex-M3 CrossWorks port
Please read all the following points before using this RTOS port.
Source Code Organization
The FreeRTOS download contains the source code for all the FreeRTOS ports so contains many more files that used by this demo.
See the Source Code Organization section for a description of the
downloaded files and information on creating a new project.
The Demo Applications
The FreeRTOS source code download includes three demo applications for the port. These include both fully preemptive tasks and co-routines. Demo-1 creates 3 tasks (including the idle task)
and 6 co-routines. Demo-2 creates 2 tasks and 7 co-routines. Both of these demos are configured to execute on the DK-LMS102 development board.
Demo-3 creates 4 co-routines and the idle task, and is configured to execute on the CrossFire LM3S102 board.
Due to the ROM and RAM constraints the standard demo tasks are not used.
Demo application hardware setup, Demo1 and Demo2
The LINK_RST jumper must be in position on the DK-LMS102 target board, all other jumpers can remain in their default positions.
Functionality, Demo1 and Demo2
When executing correctly the Demo-1 application will behave as follows:
The demo includes functionality that checks all the tasks and co-routines are executing as expected. If an error is located in any task or co-routine
LED7 will come on. This functionality can be tested by removing the loopback connector while the demo is executing.
Demo application hardware setup, Demo3
The CrossFire LM3S102 board does not require any special setup. It connects directly to the host PC via the built in USB connection and does not require
an external JTAG interface.
Functionality, Demo3
When executing correctly the Demo-3 application will flash the three coloured LEDs in a rotation pattern, the speed of which is set by the potentiometer.
Building and executing the demo applications
The CrossWorks solution FreeRTOS/Demo/CORTEX_LM3S102_Rowley/RTOSDemo.hzp contains all three demo projects and two configurations. The 'Flash Debug' configuration
must be selected for debug sessions. The 'Flash Release' configuration must be selected for running the demo stand alone (not through the debugger).

Selecting the build configuration
To download then execute the demo:

Selecting the project to build

Selecting target
Configuration and Usage Details
RTOS Port specific configuration
Configuration items specific to these demos are contained in the respective FreeRTOS/Demo/CORTEX_LM3S102_ROWLEY/Demox/FreeRTOSConfig.h files. The
constants defined in these file can be edited to suit your application. In particular - the definition
configTICK_RATE_HZ is used to set 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.
Interrupt service routines
The interrupt vector table is contained within FreeRTOS/Demo/CORTEX_LM3S102_ROWLEY/demox/vectors.s and can be populated as required. In the demo applications
the vector table remains in flash.
Switching between the pre-emptive and co-operative real time kernels
Set the definition configUSE_PREEMPTION within FreeRTOS/Demo/CORTEX_LM3S102_ROWLEY/Demox/FreeRTOSConfig.h to 1 to use pre-emption or 0
to use co-operative. The demo application will only execute correctly with configUSE_PREEMPTION set to 0 if configIDLE_SHOULD_YIELD is set to 1.
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_1.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.
Serial port driver
It should also be noted that the serial drivers are written to test some of the real time kernel features - and they are not
intended to represent an optimized solution.
Any and all data, files, source code, html content and documentation included in the FreeRTOS 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..