TI MSP430 (MSP430F449) RTOS Port
for the CrossWorks Development Tools
[RTOS Ports]

The port was developed on an ES449 development/prototyping board from SoftBaugh (instructions are provided should you wish to use an alternative development board), using the CrossWorks MSP430 compiler and a SoftBaugh FETP parallel port JTAG interface

The ES449 is a neat little MSP430F449 based prototyping board. It allows easy access to the MSP430 peripherals and includes an LCD display - great for debugging! The FETP / CrossWorks interface is seamless and fast making this a very easy to use development platform.

FreeRTOS V5.1.0 upgraded this port and demo to permit tasks to use the MSP430 low power modes 1 to 3.

IMPORTANT! Notes on using the CrossWorks MSP430 RTOS port

1. Source Code Organization
2. The Demo Application
3. Configuration and Usage Details
4. Selecting the Port to Use

Source Code Organization

The CrossWorks project used to build the MSP430 FreeRTOS demo is located in the Demo/msp430_CrossWorks directory.

The Demo Application

Functionality

The single on board LED is used by one of the ComTest tasks. It is toggled every time a character is received on the serial port.

The demo application creates 10 tasks - 9 of the standard demo application tasks and the idle task. When executing correctly the demo application will behave as follows:

• The first three '*' characters on the LCD are under control of the 'flash' tasks. Each will flash at a constant frequency, with the first '*' being the slowest and the third being the fastest.

• The on board LED will flash each time a character is received on the serial port (see the hardware setup section below).

• Not all the tasks update the LCD so have no visible indication that they are operating correctly. Therefore a 'Check' task is created whose job it is to ensure that no errors have been detected in any of the other tasks.

  The '*' in the fifth position on the LCD is under control of the 'Check' task. Every three seconds the 'Check' task examines all the tasks in the system to ensure they are executing without error. It then toggles '*' 5. If '*' 5 is toggling every three seconds then no errors have ever been detected. The toggle rate increasing to 500ms indicates that the 'Check' task has discovered at least one error.

Demo application hardware setup

The demo application uses the LCD in place of LEDs so no other hardware setup is required.

Building

1. Open the project file FreeRTOS/Demo/MSP430_CrossWorks/RTOSDemo.hzp from within the CrossStudio IDE.

2. Select the required build (Debug or Release).
   
   Selecting the required build

3. Select "Build Solution" from the CrossStudio project menu or simply press F7.

Downloading and executing

1. Connect the FETP JTAG interface between the target and host. The target will be powered via the FETP JTAG interface and no other power source should be connected.

2. Select "Connect MSP430 Flash Emulation Tool" from the CrossStudio Target menu.

3. Select "Start Debugging" from the CrossStudio Debug menu. The MSP430 Flash will be automatically programmed with the demo application.

Configuration and Usage Details

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 optimised solution.

RTOS port specific configuration

Each port #defines 'BaseType_t' to equal the most efficient data type for that processor. This port defines BaseType_t to be of type short.

Note that vPortEndScheduler() has not been implemented.

To use a part other than an MSP430F449

• prvSetupTimerInterrupt() in Source/portable/Rowley/MSP430F449/port.c configures the microcontroller timer to generate the RTOS tick.
• Port, memory access and system clock configuration is performed by prvSetupHardware() within Demo/MSP430_CrossWorks/main.c.
• The serial port drivers.
• Register location definitions are provided by the file msp430x44x.h which is included at the top of Demo/MSP430_CrossWorks/FreeRTOSConfig.h.
• RAM size - see Memory Allocation below.

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

Compiler options

Memory allocation

Interrupt Service Routines

1. The officially supported version that uses the extensions provided by the Rowley compiler to implement interrupt service routines completely in C.
2. A contributed port that required interrupt service routines to have assembly function wrappers.

Method 1 only requires C code so is simpler to implement than method 2. It only saves and restores the task context when a context switch is actually required, so can also be more efficient. However - a context switch being performed within the interrupt will result in some processor registers being saved twice (once on interrupt entry, and then again for the context switch). This means the stack allocated to each task will need to be larger when using method 1 compared to that required when using method 2.

Writing ISRs - Method 1

1. Set the pre-processor macro configINTERRUPT_EXAMPLE_METHOD to 1. The supplied demo application defines configINTERRUPT_EXAMPLE_METHOD within FreeRTOSConfig.h.
2. Use the __interrupt[ ] function qualifier to implement interrupt service routines within C files.
3. If using low power modes - ensure __bic_SR_register_on_exit(SCG1 + SCG0 + OSCOFF + CPUOFF) is called prior to exiting the interrupt service routine.
4. Use the standard taskYIELD() macro should a context switch be required from within the interrupt routine.

void vRxISR( void ) __interrupt[ UART1RX_VECTOR ]
{
signed char cChar;
BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    /* Get the character from the UART and post it on the queue of Rxed
    characters. */
    cChar = U1RXBUF;

    xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken );

    if( xHigherPriorityTaskWoken )
    {
        /*If the post causes a task to wake force a context switch
        as the woken task may have a higher priority than the task we have
        interrupted. */
        taskYIELD();
    }

    /* Make sure any low power mode bits are clear before leaving the ISR. */
    __bic_SR_register_on_exit( SCG1 + SCG0 + OSCOFF + CPUOFF );
}

Writing ISRs - Method 2

1. Set the pre-processor macro configINTERRUPT_EXAMPLE_METHOD to 2. The supplied demo application defines configINTERRUPT_EXAMPLE_METHOD within FreeRTOSConfig.h.
2. Provide an assembly function that will be installed as the interrupt handler routine. The required format of this function is demonstrated below. Note the assembly file must include the portasm.h header file to gain access to the required portSAVE_CONTEXT and portRESTORE_CONTEXT assembly macros.
3. Provide a standard C function that is called by the assembly file wrapper to perform the actual interrupt handling work - again see below for an example.
4. Use the portYIELD_FROM_ISR() macro should a context switch be required from within the interrupt routine.

/* Ensure the required header files are included. */
#include "FreeRTOSConfig.h"
#include "portasm.h"

.CODE

/* Example wrapper for the Rx UART interrupt. */
_vUARTRx_Wrapper:

    /* portSAVE_CONTEXT must be the first macro to be called.  This is defined within
    portasm.h. */
    portSAVE_CONTEXT

    /* Following portSAVE_CONTEXT the C portion of the handler can be called. */
    call #_vRxISR

    /* Finally portRESTORE_CONTEXT must be called at the end of the wrapper.  This too
    is defined within portasm.h. */
    portRESTORE_CONTEXT


/******************************************************************/


    /* The wrapper must be installed as the interrupt handler. */

    .VECTORS
    .KEEP

    ORG    UART1RX_VECTOR
    DW    _vUARTRx_Wrapper

    END

/* This is the standard C function called by the assembly file wrapper. */
void vRxISR( void )
{
signed char cChar;
BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    /* Get the character from the UART and post it on the queue of Rxed
    characters. */
    cChar = U1RXBUF;

    xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken );

    /*If the post causes a task to wake force a context switch
    as the woken task may have a higher priority than the task we have
    interrupted. */
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}