Infineon XMC4000 ARM Cortex-M4F Demo
Supporting IAR, Keil, GCC and Tasking compilers
[RTOS Ports]
Introduction
This page documents the demo application that targets the Infineon XMC4000 range
of ARM Cortex-M4F microcontrollers.
Pre-configured projects are provided for each of the following ARM Cortex-M4 compilers:
Each of the four projects contains three build configurations, one build configuration
targeting one of the following XMC4000 Hexagon Application Kits:
Each build configuration can be compiled to create either a simple blinky demo,
or a comprehensive test and demo application. Build instructions are provided
below.
Screen shot of the FreeRTOS state viewer plug-in
that ships with the IAR IDE
Note 1: The projects in the FreeRTOS download include special settings to
workaround an XMC4000 silicon errata. Please see the
build instructions for the
individual compilers below for more information.
Note 2: The IAR project will fail to build and be corrupted (so it can no longer
be used with any IAR version) if it is opened
in a version of EWARM that is older than the version that was used to originally
create the project.
IMPORTANT! Notes on using the XMC4000 ARM Cortex-M4F 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 download contains the source code for all the FreeRTOS ports, so
contains many more files than are needed by the XMC4000 demos.
See the Source Code Organization
section for a description of the downloaded files and information on creating a
new project.
-
The IAR Embedded Workspace project is called RTOSDemo.eww and is located in the
FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_IAR directory.
-
The Keil project is called RTOSDemo.uvproj and is located in the
FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_Keil directory.
-
The Dave project has the usual Eclipse project name .project and
is located in the FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_GCC_Dave
directory.
-
The Tasking project has the usual Eclipse project name .project and
is located in the FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_GCC_Tasking
directory.
Building and Running the ARM Cortex-M4F RTOS Application
The RTOS demo projects can be configured to build either
a simple blinky project, or a comprehensive test and demo application. The constant
mainCREATE_SIMPLE_BLINKY_DEMO_ONLY, which is defined at the top of main.c, is used
to switch between the two. The simple demo is created if mainCREATE_SIMPLE_BLINKY_DEMO_ONLY
is set to 1. The comprehensive demo is created if mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set
to 0.
The demo uses the LED built onto each Hexagon Application Kit board, so no
hardware setup is required.
The XMC4200 and XMC4400 Hexagon kits have a built in J-Link debugger interface. These boards
can be connected directly to the host computer using a USB cable with no other
connections required. These Hexagon boards each have two USB connectors, so
be careful to use the one marked "Debug USB".
The XMC4500 Hexagon kit does not have a build in J-Link, and therefore
requires two connections:
- To provide an interface to the debugger:
Connect an external debugger interface between the host computer
and one of the two debug ports provided on the XMC4500 Hexagon PCB. As supplied the
projects are configured to use a J-Link, so the use of any other
compatible device will require the project options to be updated
as appropriate.
-
To provide power to the hardware:
Connect a USB cable between the USB OTG connector on the XMC4500 Hexagon PCB
and any convenient USB host.
The following sub-sections provide instructions on using each of the four
supported ARM Cortex-M4 compilers.
-
Building with the IAR Embedded Workbench
-
Building with ARM Keil
-
Building with ARM GCC using the DAVE Eclipse IDE
-
Building with Tasking ARM VX-toolset
Note: If the XMC4000 device you are using includes errata number PMC_001
then WORKAROUND_PMU_CM001 must be #define'ed to 1 in FreeRTOSConfig.h, and likewise
be set in the start-up files. The project in the FreeRTOS download already contains
these settings.
-
Open FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_IAR/RTOSDemo.eww in the
IAR Embedded Workbench IDE.
-
Set the build configuration to the correct option for your target hardware.
Build configurations are provided for the XMC4200, XMC4400 and XMC4500
Hexagon Application kits. The active build configuration is set using the drop down list
at the top of the EWARM IDE's Workspace window.
-
Select "Rebuild All" from the IAR Embedded Workbench "Project" menu (or press F7) to build
the demo project.
-
Select "Download and Debug" from the IAR Embedded Workbench "Project"
menu to program the microcontroller flash memory and start a debug
session.
Note: If the XMC4000 device you are using includes errata number PMC_001
then WORKAROUND_PMU_CM001 must be #define'ed to 1 in FreeRTOSConfig.h, and likewise
be set in the start-up files. The project in the FreeRTOS download already contains
these settings.
-
Open FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_Keil/RTOSDemo.uvproj in the
Keil IDE.
-
Set the build configuration (called the Target in the Keil IDE)
to the correct option for your target hardware.
Build configurations are provided for the XMC4200, XMC4400 and XMC4500
Hexagon Application kits. The active build configuration is normally
shown in a drop down list in the IDE's menu tool bar.
-
Select "Rebuild Target" from the Keil "Project" menu (or press F7) to build
the demo project.
-
Select "Start/Stop Debug Session" from the Keil "Project"
menu to program the microcontroller flash memory and start a debug
session.
Note: If the XMC4000 device you are using includes errata number PMC_001
then WORKAROUND_PMU_CM001 must be #define'ed to 1 in FreeRTOSConfig.h, and likewise
be set in the start-up files. The project in the FreeRTOS download already contains
these settings.
-
Execute the CreateProjectDirectoryStructure.bat
batch file located in the FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_GCC_Dave
directory before opening the project.
This will copy the required files into local directories.
-
Start the DAVE Eclipse IDE and either create a new or select an existing
workspace when prompted.
-
Select "Import" from the IDE's "File" menu. The dialogue box shown below
will appear. Select "General->Existing Project into Workspace", as shown below.
The dialogue box that appears when "Import" is first clicked
-
In the next dialogue box, select FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_GCC_Dave
as the root directory. 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).
Make sure RTOSDemo is checked, and "Copy projects into workspace" is not checked
-
After the project has been imported, right click on the project name in the DAVE
Eclipse project explorer window, then on the pop-up menu select
"Build Configurations->Set Active" to set
the build configuration to the correct option for your target hardware.
Build configurations are provided for the XMC4200, XMC4400 and XMC4500
Hexagon Application kits.
-
Select "Rebuild Project" from the DAVE Eclipse "Project" menu to build
the demo project.
-
Select "Debug" from the Eclipse "Run"
menu to configure a launch configuration that can be used to program the
microcontroller flash memory and start a debug session.
Note:
At the time of writing each build configuration within a DAVE project
must target the exact same microcontroller part number. The delivered build configurations
are however configured to selectively include and exclude chip specific
files, so the projects will be built correctly, although an additional step
is required when starting a debug session; Check the Debug launch
configuration to ensure it is configured to target the hardware actually
being used (see image below). It is likely that the debugger will also issue a warning
when a debug session is launched - the warning can be ignored
providing the launch configuration is configured correctly for the hardware
in use.
Selecting the target in the debug launch configuration
Note: If the XMC4000 device you are using includes errata number PMC_001
then the linker macro SILICON_BUG_PMC_CM_001 must be in the project settings.
The project in the FreeRTOS download already contains this setting.
-
Execute the CreateProjectDirectoryStructure.bat
batch file located in the FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_GCC_Tasking
directory before opening the project.
This will copy the required files into local directories.
-
DAVE and Tasking both use the Eclipse IDE, so you can
follow the instructions provided for building the application with DAVE,
just ensure to import the project into Eclipse from the
FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4000_GCC_Tasking
directory.
Demo Application Functionality
The simply blinky example
The simple blinky example is created when mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set
to 1. mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is defined in main.c
main() calls main_blinky():
-
The main_blinky() Function:
main_blinky() creates a queue, a queue send task, and a queue receive
task, before starting the scheduler.
-
The Queue Send Task:
The queue send task is implemented by the prvQueueSendTask() function in main_blinky.c.
prvQueueSendTask() sends the value 100 to the queue every 200 milliseconds.
-
The Queue Receive Task:
The queue receive task is implemented by the prvQueueReceiveTask() function
in main_blinky.c.
prvQueueReceiveTask() blocks to wait for data to arrive on the queue.
Each time the value 100 is received from the queue it toggles the LED.
As data is sent to the queue every 200ms, the LED will toggle every
200ms.
The comprehensive test and demo application
The comprehensive example is created when mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set
to 0. mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is defined in main.c.
main() calls main_full():
-
The main_full() Function:
main_full() creates a set of standard demo tasks, some application specific
test tasks, and a timer, before starting the scheduler.
-
The "Reg Test" Tasks:
The reg test tasks test the context switching mechanism by filling each
MCU register with a known value, then continuously checking that each
register maintains its expected value for the lifetime of the task.
-
The "Check" software Timer:
The "Check" software timer monitors the status of all the other tasks in
the system, looking for a task either stalling or reporting an error.
It toggles an LED each time it is called.
If the LED is toggling every three seconds then the check task has not
detected any stalled tasks or received any error reports. If the LED
is toggling every 200ms then at least one error has been found.
Interrupt service routines
Interrupt service routines that cause a context switch have
no special requirements.
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.
An example interrupt handler
called Dummy_IRQHandler() is provided at the end of main.c as a reference implementation.
Dummy_IRQHandler() is also replicated below.
void Dummy_IRQHandler(void)
{
long lHigherPriorityTaskWoken = pdFALSE;
/* Clear the interrupt if necessary. */
Dummy_ClearITPendingBit();
/* 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. Only FreeRTOS API functions
that end in "FromISR" can be called from an ISR! */
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 );
}
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
ARM Cortex-M microcontroller manufacturers implement a different number of priority bits and supply library
functions that expect priorities to be specified in different ways. For example,
on Infineon ARM Cortex-M4 microcontrollers, the lowest priority you can specify is in fact 63 - 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 priority bits are assigned as
being preemption priority bits, and none as sub priority bits, as they are in the provided
demo.
Note that the following lines are included in FreeRTOSConfig.h to map the FreeRTOS
interrupt handler function names onto the CMSIS interrupt handler function names.
This allows the linker scripts provided by the compiler tool vendors to be used
without modification.
#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
RTOS port specific configuration
Configuration items specific to these demos are contained in the FreeRTOSConfig.h
file located in the same directory as the project file. The
constants defined in FreeRTOSConfig.h can be edited to meet the needs of your application. In particular -
Each port #defines 'BaseType_t' to equal the most efficient data type for that
processor. All ARM Cortex-M4F ports define BaseType_t to be of type long.
Note that vPortEndScheduler() has not been implemented.
Memory allocation
Source/Portable/MemMang/heap_4.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
full information.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|
