NXP LPC43xx ARM Cortex-M4F Demo
Using Keil MDK development tools
This page documents a FreeRTOS ARM Cortex-M4F demo application that targets an NXP
A Keil project is provided that is pre-configured to run on the LPC4350 development board provided
by Hitex. The LPC4350 demo project will evolve over the coming weeks
to also include support for the LPC4350’s ARM Cortex-M0 based co-processor.
The demo configures the LPC4350 to run at 204MHz. See the notes in the RTOS
configuration and usage section below.
The FreeRTOS ARM Cortex-M4F port supports a full interrupt nesting model, and never
completely disable interrupts. The port can only be used with hardware
floating point support turned on in the compile time options of the project
used to build the source files. ARM Cortex-M4 devices that don’t include a floating
point unit should not use this port, but instead use the FreeRTOS ARM Cortex-M3 port layer.
Note that Keil MDK version 4.2.2 or above is required to ensure the no_allow_fpreg_for_nonfpdata
compiler option is available.
IMPORTANT! Notes on using the FreeRTOS Keil LPC4300 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 NXP LPC4350 demo. See the
Source Code Organization section for a description
of the downloaded files, and information on creating a new project.
The Keil MDK demo project for the ARM Cortex-M4F core on the LPC4350 is called M4.uvproj,
and is located in the FreeRTOS/Demo/CORTEX_M4F_M0_LPC43xx_Keil/M4 directory of the
official FreeRTOS .zip file download. The FreeRTOS/Demo/CORTEX_M4F_M0_LPC43xx_Keil/M0
directory is currently empty, and included as a placeholder for the near future addition of
support for the LPC4350’s co-processor core.
The NXP LPC4350 Demo Application
This demo application demonstrates:
The demo application can be configured to provide a very simply ‘blinky’ style
demonstration, or a full and comprehensive test and demonstration of the
FreeRTOS functionality. The configuration built is controlled by the constant
#define mainCREATE_SIMPLE_LED_FLASHER_DEMO_ONLY, which is defined in
Demo application tasks are split between standard demo tasks, and demo specific
tasks. Standard demo tasks are used by all FreeRTOS ports and demo applications.
They have no specific purpose, other than to demonstrate the FreeRTOS API, and test the port.
Set to 1
This creates a very simple example that creates three
standard demo “flash” tasks. Each of the three tasks toggles an
LED at a fixed but different frequency. LEDs LED3, LED2 and LED1
Set to 0
This is a very comprehensive demo that creates 46 tasks before
starting the RTOS scheduler. It then continuously creates and
deletes a further two tasks while the application is executing.
The demo includes a lot of queues, a software timer, and various different types of semaphore.
The tasks consist mainly of the
standard demo tasks.
Application specific “register test” tasks are also created.
These start by filling all the generic, and all the floating point registers, with known
values. The tasks then repeatedly check that
each register maintains the value written to it for the lifetime of
the task. The tasks run at the idle priority, so will exit and re-enter
the Running state often. The two register check
tasks each use different values, and a register containing an
unexpected value is symptomatic of an error in the context switching
A ‘check’ software timer is created that periodically inspects the standard
demo tasks, and register test tasks, to ensure all the tasks are functioning
as expected. The check software timer’s
callback function toggles LED LED0. This gives visual feedback of the
system health. If LED LED0 is toggling every 3 seconds, then the
check software timer has not discovered any problems. If LED LED0 is
toggling every 200 milliseconds, then the check software timer has
discovered a problem in one or more tasks.
Like the simple flasher demo, the comprehensive demo
creates the standard demo flash tasks, which toggle LEDs LED3, LED2 and LED1
at fixed but different frequencies.
Hardware set up
The demo uses the LEDs that are soldered directly onto the Hitex PCB, so no
hardware set up is required.
Building and executing the demo application
Ensure the target hardware is connected to the host computer using a
suitable interface. The project has been tested with both a ULINK2 and a ULINK ME.
Open the M4.uvproj Keil project from within
the Keil IDE.
Select “Build” from the IDE’s “Project” menu, or simply press F7. The project
should build without any errors or warnings.
When the build completes, select “Start/Stop Debug Session” from the IDE’s
“Debug” menu (or just press CTRL+F5) to program the microcontroller flash memory,
and start a debug session. The execution will break on entry to the main()
Cortex-M4F FreeRTOS port specific configuration
Configuration items specific to this demo are contained in FreeRTOS/Demo/CORTEX_M4F_M0_LPC43xx_Keil/M4/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.
configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY
Whereas configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
are full eight bit shifted values, defined to be used as raw numbers directly
in the ARM Cortex-M4F NVIC registers, configLIBRARY_LOWEST_INTERRUPT_PRIORITY
are exact equivalents, but defined using just the 5 priority bits available on the LPC4300.
The CMSIS library function NVIC_SetPriority() requires the unshifted 5 bit format.
Attention please!: See the page dedicated to setting interrupt priorities on ARM Cortex-M devices. Remember that ARM Cortex-M 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-M core is in fact 255 – however different
Cortex-M vendors implement a different number of priority bits and supply library
functions that expect priorities to be specified in different ways. For example,
on LPC ARM Cortex-M microcontrollers, the lowest priority you can specify is in fact 31 – 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 five priority bits are assigned as
being preemption priority bits, and none as sub priority bits, as they are in the provided
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.
Core clock configuration
The demo runs the LPC4350 clock at 204MHz. To achieve this it is necessary
for the functions that configure the parallel flash memory controller to execute out of
RAM. The mapping of these functions is performed within the linker script itself (scatter file),
and the code that steps the core clock up to 204MHz is contained in Hitex_fast_startup.c.
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.
The following source code snippet is provided as an example. The interrupt
uses a semaphore to synchronise with a task (not shown), and calls portEND_SWITCHING_ISR
to ensure the interrupt returns directly to the task.
long lHigherPriorityTaskWoken = pdFALSE;
/* Clear the interrupt if necessary. */
/* This interrupt does nothing more than demonstrate how to synchronise a
task with an interrupt. A semaphore is used for this purpose. Note
lHigherPriorityTaskWoken is initialised to zero. */
xSemaphoreGiveFromISR( xTestSemaphore, &lHigherPriorityTaskWoken );
/* If there was a task that was blocked on the semaphore, and giving the
semaphore caused the task to unblock, and the unblocked task has a priority
higher than the current Running state task (the task that this interrupt
interrupted), then lHigherPriorityTaskWoken will have been set to pdTRUE
internally within xSemaphoreGiveFromISR(). Passing pdTRUE into the
portEND_SWITCHING_ISR() macro will result in a context switch being pended to
ensure this interrupt returns directly to the unblocked, higher priority,
task. Passing pdFALSE into portEND_SWITCHING_ISR() has no effect. */
portEND_SWITCHING_ISR( lHigherPriorityTaskWoken );
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 ARM Cortex-M4F 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) Amazon Web Services, Inc. or its affiliates. All rights reserved.