The XMC1300 boot kit
Pre-configured projects are provided for each of the following ARM Cortex-M0 compilers:
Each project contains three build configurations, with a a build configuration for each of the following three XMC1000 evaluation boards:
Each build configuration can be further configured through the use of a #define to create either a simply blinky style application, or a comprehensive test and demo application.
Note: If the IAR 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 from the main FreeRTOS zip file download before it
can be built even after the EWARM version has been updated.
See also the FAQ My application does not run, what could be wrong?
Project files for all three supported compilers are located in the FreeRTOS/Demo/CORTEX_M0_Infineon_XMC1000_IAR_Keil_GCC directory.
Set mainCREATE_SIMPLE_BLINKY_DEMO_ONLY to one to create the basic Blinky demo. Set mainCREATE_SIMPLE_BLINKY_DEMO_ONLY to 0 to create the more comprehensive test and demo application. Ensure to set the mainCREATE_SIMPLE_BLINKY_DEMO_ONLY constant before building the project.
The demo uses the LEDs that are built onto the boot kit's PCB, so no hardware setup is required. Any jumpers and switches should be left in their default position.
The following sub-sections provide instructions on using each of the three supported ARM Cortex-M0 compilers and tool chains.
main_blinky() creates one queue, and two tasks. It then starts the scheduler.
The queue send task is implemented by the prvQueueSendTask() function in main_blinky.c. prvQueueSendTask() sits in a loop that causes it to repeatedly block for 200 milliseconds before sending the value 100 to the queue that was created within main_blinky().
The queue receive task is implemented by the prvQueueReceiveTask() function in main_blinky.c. prvQueueReceiveTask() sits in a loop repeatedly blocking on an attempt to read data from the queue that was created within main_blinky(). When data arrives the task automatically unblocks, checks the value of the data, and if the value equals the expected 100, toggles an LED.
The 'block time' parameter passed to the queue receive function specifies that the task should be held in the Blocked state indefinitely to wait for data to be available on the queue. The queue receive task will only leave the Blocked state when the queue send task writes to the queue. As the queue send task writes to the queue every 200 milliseconds, the queue receive task leaves the Blocked state every 200 milliseconds, and therefore toggles the LED every 200 milliseconds.
main_full() creates a set of standard demo tasks, some application specific test tasks, and a timer. It then starts the scheduler.
These fill the registers with known values, then check that each register maintains its expected value for the lifetime of the task. Each task uses a different set of values. The reg test tasks execute with a very low priority, so get preempted very frequently. A register containing an unexpected value is indicative of an error in the context switching mechanism.
This task does nothing but block on a semaphore that is 'given' from the tick hook function (which is defined in main.c). It toggles LED 4 each time it receives the semaphore. The Semaphore is given every 50ms, so LED 4 toggles every 50ms.
The check software timer period is initially set to three seconds. Its callback function checks that all the standard demo tasks, and the register check tasks, are not only still executing, but are executing without reporting any errors. If the check timer callback discovers that a task has either stalled, or reported an error, then it changes the period of the check timer from the initial three seconds, to just 200ms. The callback function also toggles LED 5 each time it is called. This provides a visual indication of the system status: If LED 5 toggles every three seconds, then no issues have been discovered. If the LED toggles every 200ms, then an issue has been discovered with at least one task.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
A dummy 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 );
}
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
This sets the frequency of the RTOS tick interrupt. The supplied value of 500Hz is useful for testing the RTOS kernel functionality, but is faster than most applications require. Lowering this value will improve efficiency.
Each port #defines 'BaseType_t' to equal the most efficient data type for that processor. All ARM Cortex-M0 ports define BaseType_t to be of type long.
Note that vPortEndScheduler() has not been implemented.