Microchip ARM Cortex-M4F CEC1302
Low Power RTOS Demo - Using the Keil, GCC and MikroC development tools
[RTOS Ports]

Introduction

• Keil uVision, using the ARM compiler
• Keil uVision, using the GCC compiler
• mikroC Pro for ARM

The project can be configured to create either a simple blinky style project that demonstrates how power can be saved by using the RTOS's tickless idle feature, or a more comprehensive test and demo application that tests the port's integrity and demonstrates many RTOS features.

IMPORTANT! Notes on using the FreeRTOS CEC1302 demo project

1. Source Code Organisation
2. The Demo Application
3. RTOS Configuration and Usage Details

Source Code Organisation

• The Keil uVision project that uses the ARM compiler is called RTOSDemo.uvprojx, and is located in the FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/Keil_Specific directory of the main FreeRTOS download.

• The Keil uVision project that uses the GCC compiler is also called RTOSDemo.uvprojx, and is located in the FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/GCC_Specific directory of the main FreeRTOS download.

• The MikroC Pro for ARM project is called RTOSDemo.mcpar, and is located in the FreeRTOS/Demo/CORTEX_M4F_CEC1302_MikroC/MikroC_Specific directory of the main FreeRTOS download.

The Microchip ARM Cortex-M4 RTOS Demo Application

Hardware set up - uVision projects

The ulLED variable is incremented by the macro configTOGGLE_LED(), which is defined in FreeRTOSConfig.h. If your target hardware has a spare LED, then configTOGGLE_LED() can be updated to make use of the LED. Otherwise ulValue can be added to the uVision IDE's data watch window, where its value will be seen to updated as the RTOS demo application executes (provided a capable debug interface is used, such as a ULINK).

The ARM compiler and GCC compiler versions of the uVision projects can also be executed on the Clicker hardware described in the next section by creating an adapter cable that maps the Mikro mProg cable to a standard ARM JTAG connector. The required pin-out is detailed in the table below (assumes a 20-pin JTAG connector).

Hardware set up - MikroC Pro for ARM project

Functionality

Functionality with configCREATE_LOW_POWER_DEMO set to 1

• Two tasks are created, an Rx task and a Tx task.

• The Rx task blocks on a queue to wait for data, blipping (turning on then off again) an LED (or toggling the ulLED variable) each time data is received. The LED is only blipped on briefly so it does not effect current consumption too much.

• The Tx task sends a value through the queue to the Rx task every 1000ms (resulting in the Rx task exiting the blocked state to blip the LED).

Observed behaviour when configCREATE_LOW_POWER_DEMO is set to 1

RTOS implementation when configCREATE_LOW_POWER_DEMO is set to 1

This CEC1302 specific tickless implementation includes the same configPRE_SLEEP_PROCESSING() and configPOST_SLEEP_PROCESSING() macros that are described on the page that documents the generic Cortex-M tickless implementation. The pre sleep macro can be defined to take additional application specific actions to improve energy efficiency before entering the low power state, and the post sleep macro can be defined to reverse any of the actions taken by the pre sleep macro. For example, if the pre-sleep macro is defined to turn a peripheral off, and the post sleep macro is defined to turn the peripheral on again, then the peripheral will automatically be turned off prior to each entry into the sleep mode, and automatically turned back on again on each exit from the sleep mode.

Functionality with configCREATE_LOW_POWER_DEMO set to 0

• Task notifications
• Event groups
• Software timers
• Queues
• Semaphores
• Mutexes
• Statically allocated RTOS objects

A 'check' task is created that periodically inspects the standard demo tasks to ensure all the tasks are functioning as expected. The check task toggles an LED (or increments the ulLED variable). This gives a visual feedback of the system health. If an LED is toggling every 3 seconds, then the check task has not discovered any problems. If the LED is toggling every 200 milliseconds, then the check task has discovered a problem in one or more tasks.

Building and executing the demo application

Using the uVision project with the GCC compiler

1. Ensure a suitable GCC compiler is installed on the host computer. The project was created and tested with the arm-none-eabi-gcc compiler, pre-built binaries for which are freely available from the launchpad.net website.

2. Open FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/GCC_Specific/RTOSDemo.uvprojx from within the Keil IDE.

3. Open the Manage Project Items window within the uVision IDE ("Project->Manage->Project Items" menu item) and set the GCC prefix and installation folder to be correct for your host computer.
   
   Setting the path to the GCC compiler binary
   Note the path does not include the training "/bin"

4. Open FreeRTOSConfig.h, and set configCREATE_LOW_POWER_DEMO to generate either the tickless low power demo, or the full test and demo application, as required.

5. Ensure the target hardware is connected to the host computer through a suitable debug connector, such as a ULINK2.

6. Select 'Rebuilt All Target Files' from the IDE's 'Project' menu, the RTOSDemo project should compile without any errors or warnings.

7. After the build completes, select "Start/STOP Debug Session" from the IDE's Debug menu to download the application to the CEC1302 ARM Cortex-M4F microcontroller RAM memory, start a debug session, and have the debugger break on entry into the main() function. If the debug session does not start as expected then ensure the debug options, and in particular the "Connect & Reset Options" section of the debug options, are set as shown below.
   
   The required connect and reset options

Using the uVision project with the ARM compiler

1. Open FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/Keil_Specific/RTOSDemo.uvprojx from within the Keil IDE.

2. Open FreeRTOSConfig.h, and set configCREATE_LOW_POWER_DEMO to generate either the tickless low power demo, or the full test and demo application, as required.

3. Ensure the target hardware is connected to the host computer through a suitable debug connector, such as a ULINK2.

4. Select 'Rebuilt All Target Files' from the IDE's 'Project' menu, the RTOSDemo project should compile without any errors or warnings, although a warning may be generated by the linker as, to enable the maximum number of tests to be added to the comprehensive demo, the linker script is configured to place both code and data in the same named section.

5. After the build completes, select "Start/STOP Debug Session" from the IDE's Debug menu to download the application to the CEC1302 ARM Cortex-M4F microcontroller RAM memory, start a debug session, and have the debugger break on entry into the main() function. If the debug session does not start as expected then ensure the debug options, and in particular the "Connect & Reset Options" section of the debug options, are set as shown by the image provided as part of the GCC instructions above.

Using the MikroC Pro compiler for ARM and the Clicker hardware

1. Open FreeRTOS/Demo/CORTEX_M4F_CEC1302_MikroC/MikroC_Specific/RTOSDemo.mcpar from within the MikroC Pro IDE.

2. Open the Search Paths window ("Projects->Edit Search Paths" menu item) and update the paths to the source files and header files to be correct for your host computer.
   
   Setting the path to source and header files
   
   

3. As provided, the MikroC demo uses the FreeRTOS/Source/portable/MemMang/heap_4.c memory allocator, and a malloc failed hook is defined. It is necessary to make a small edit to the heap_4.c source file to make it compatible with the MikroC compiler. Open heap_4.c and locate the following code:

   #if( configUSE_MALLOC_FAILED_HOOK == 1 )
   {
       if( pvReturn == NULL )
       {
           extern void vApplicationMallocFailedHook( void ); /* Move this line. */
           vApplicationMallocFailedHook();
       }
       else
       {
           mtCOVERAGE_TEST_MARKER();
       }
   }
   #endif
   		

   Move the line highlighted (the line starting 'extern') from its current position to the top of the source file so it has file scope rather than block scope.

Ensure the Clicker hardware is powered through its USB port, and connected using a MikroProg flash programmer, before selecting "mE Programmer" from the "Tools" menu to download the executable image to the CEC1302 ARM Cortex-M4F microcontroller. If the download does not start as expected then ensure the Programmer/Debugger Options are as shown in the image below ("Tools->Programmer/Debugger Options" menu item).

The required programmer and debug options

RTOS Configuration and Usage Details

ARM Cortex-M4 FreeRTOS port specific configuration

• configTICK_RATE_HZ

  This sets the frequency of the RTOS tick interrupt. The setting used by this demo depends on the configCREATE_LOW_POWER_DEMO setting.

• 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-M4 NVIC registers, configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY are equivalents that are defined using just the 3 priority bits implemented in the CEC1302 NVIC. These values are provided because the CMSIS library function NVIC_SetPriority() requires the un-shifted 3 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 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 Microchip CEC1302 ARM Cortex-M4 microcontrollers, the lowest priority you can specify is in fact 7 - 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.

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.

Aggregated and disaggregated interrupts

Interrupt service routines

Note that portYIELD_FROM_ISR() will leave interrupts enabled.

The following source code snippet is provided as an example. The interrupt uses a direct to task notification to synchronise with a task (not shown), and calls portYIELD_FROM_ISR() to ensure the interrupt returns directly to the task if the task has an equal or higher priority than the interrupted task.

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 task notification is used for this purpose.
    Note lHigherPriorityTaskWoken is initialised to zero. */
    vTaskNotifyGiveFromISR( xHandlingTask, &xHigherPriorityTaskWoken );

    /* If the notified task was blocked waiting for the notification, and the
    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 vTaskNotifyGiveFromISR().  Passing
    pdTRUE into the portYIELD_FROM_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 portYIELD_FROM_ISR()
    has no effect. */
    portYIELD_FROM_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 configuration constant (or configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY).

Resources used by FreeRTOS

Switching between the pre-emptive and co-operative RTOS kernels

Compiler options

Memory allocation

Miscellaneous