STM32 Connectivity Line ARM Cortex-M3 demo
Including a uIP Embedded Web Server Example
[Embedded Ethernet Examples]
The demo presented on this page uses:
uIP is licensed separately from FreeRTOS. Users must familiarise themselves with the uIP license.
FreeRTOS has made some modifications to the uIP stack since this demo was created. See the Embedded Ethernet Examples List page for more information.
The FreeRTOS ARM Cortex-M3 port includes a full interrupt nesting model. Interrupt priorities must be set in accordance with the
instructions on the Customisation page for correct operation.
IMPORTANT! Notes on using the ST ARM Cortex-M3 Web Server Demo
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 CrossWorks workspace for the STM32F107 demo is located in the FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley directory.
The FreeRTOS zip file download contains the files for all the ports and demo application projects. It therefore contains many more
files than used by this demo. See the Source Code Organization section for a description
of the downloaded files and information on creating a new project.
The Demo Application
web server configuration
Ensure that jumper JP4 is set so that JP4 pins 1 and 2 are shorted - this routes the output of the external 25MHz crystal to the PHY.
Jumpers JP3, JP11, JP12 and JP13 need to be shorting pins 2 and 3, which should be the default setting.
Connect the STM3210C evaluation board to a computer running a web browser either directly using a point to point (crossover)
cable, or via an Ethernet switch using a standard Ethernet cable.
The IP address used by the demo is set by the constants configIP_ADDR0 to
configIP_ADDR3 within the file FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/FreeRTOSConfig.h. The MAC address and net mask are configured
within the same header file.
The IP addresses used by the web browser computer and the STM32 development board must be compatible.
This can be ensured by making the first three octets of both IP addresses identical.
For example, if the web browser computer uses IP address
192.168.100.1, then the development board can be given any address in the range 192.168.100.2 to 192.168.100.254 (barring
any addresses already present on the network).
Building and executing the demo application
- Open the FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/RTOSDemo.hzp solution from within the CrossStudio IDE.
- Select the appropriate build configuration - either "THUMB Flash Debug" if you wish to debug the application, or "THUMB Flash Release" if
you wish to run the application stand alone (without the debugger). Note that the "Thumb Flash Debug" configuration can only be used in
combination with the debugger - it can not be used to execute the demo simply by resetting the board.
Selecting the build configuration
- Select "Build RTOSDemo" from the "Build" menu - the solution should build with no errors or warnings.
- Connect your chosen JTAG interface between the host computer and the target hardware (the project was developed using a J-Link), apply
power to the target, then connect to the target using the appropriate item from the IDE "Target" menu.
- Select "Start Debugging" from the "Debug" menu. The microcontroller Flash memory will be programmed and the debugger will break at main.
The ST peripheral library
Please note that the peripheral library utilised by the demo application is neither re-entrant nor event driven.
During its initialisation, the demo application accesses IO port configuration from within more than one task. This raises the possibility
of problems related to re-entrancy (or lack of it). No attempt is made to guard against this. If this proves problematic then
place the initialisation library calls inside critical sections.
The LCD driver uses a polled SPI interface. Currently the LCD gatekeeper task is configured to execute at a medium priority - resulting in lower
priority tasks not getting any processing time while the SPI interface is being polled. The task can be configured to execute at
the lowest priority, but this results in visibly slower LCD updates. A much more efficient solution would be to re-implement the
driver to make use of the DMA and be event driven.
The demo application creates 30 tasks prior to starting the RTOS scheduler. These tasks consist
predominantly of the standard demo application tasks (see the demo application
section for details of the individual tasks). Their only purpose is to test the RTOS kernel port and provide
a demonstration of how to use the various API functions.
The following tasks and tests are created in addition to the standard demo tasks:
- High priority interrupt test
A 20KHz periodic interrupt is generated using a timer to demonstrate
the use of the 'configKERNEL_INTERRUPT_PRIORITY' and 'configMAX_SYSCALL_INTERRUPT_PRIORITY' configuration constants. The interrupt
service routine measures the number of processor clocks that occur between each interrupt - and
in so doing measures the jitter in the interrupt timing. The maximum measured jitter time is
latched in the ulMaxJitter variable, and displayed on the LCD display by the 'Check' task as
described below. The fast interrupt is configured and handled in the timertest.c source file.
This demonstrates how the RTOS kernel can be configured so as to have no impact on higher priority
The ARM Cortex-M3 core has the ability to hasten the entry into an interrupt service routine
(and therefore reduce latency) by up to 8 cycles should a high priority interrupt occur while a
lower priority interrupt is already being serviced. The measured jitter time should therefore be
no more than about 8 clock cycles.
- LCD task
The LCD task is a 'gatekeeper' task. It is the only task that is permitted to access the
LCD directly. Other tasks or interrupts wishing to write a message to the LCD
send the message on a queue to the LCD task instead of accessing the LCD themselves.
The LCD task just blocks on the queue waiting for messages - waking and displaying
the messages as they arrive.
- Check function - called from the tick hook
This only executes every five seconds. Its main function is to check that all the
standard demo tasks are still operational. Should any unexpected behaviour be discovered
within a standard demo task the 'check' function will write an error to the LCD (via
the LCD task). If all the demo tasks are executing with their expected behaviour
then the check task writes PASS and the maximum measured jitter time in nano seconds to the
LCD (again via the LCD task). The jitter time is measured within the high priority interrupt
test as described above.
The check function executes within the context of an interrupt service routine so
is a good example of how using a gatekeeper task to control the LCD permits even
interrupts to output LCD messages.
- uIP task
This is the task that handles the uIP stack. All TCP/IP processing is performed in this task.
When executing correctly the demo application will behave as follows:
- The 'check' function will write "PASS" and the maximum measured jitter time to the LCD
every 5 seconds.
- LEDs 1, 2 and 3 are under the control of the standard 'flash' tasks. Each will toggle at a fixed but different frequency.
- The target hardware will serve the web pages described below to a standard web browser. To connect to the target:
- Open a web browser on the connected computer.
- Type "HTTP://" followed by the target IP address into the browsers address bar.
Entering the IP address into the web browser
(obviously use the correct IP address for your system)
Served Web Pages
The top of each served page includes a menu containing a link to every other page.
The served RTOS stats page showing status information on each task in the system.
The served run time stats page showing the processor utilisation of each task.
The served IO page
The IO page provides a simple interface that permits data to be sent to LED 4 and LCD on the development board.
The check box permits the state of LED 4 to be set and queried. The text box can be used to write a message to the LCD,
but does not query the text currently being display.
Changes are sent to the target hardware by clicking the "Update IO" button.
The TCP Stats and Connections pages display run time networking information.
RTOS port specific configuration
Configuration items specific to these demos are contained in FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/FreeRTOSConfig.h. The
constants defined in this file can be edited to suit your application. In particular -
Attention please!: Remember that ARM Cortex-M3 cores use numerically low priority numbers to represent HIGH
priority interrupts, which 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 can 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.
This sets the frequency of the RTOS tick. 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.
The lowest priority on a ARM Cortex-M3 core is in fact 255 - however different ARM Cortex-M3 vendors implement a different number of priority bits and supply library
functions that expect priorities to be specified in different ways. Use the supplied examples as a reference.
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.
Note that vPortEndScheduler() has not been implemented.
Interrupt service routines
In the demo application the vector table remains in flash.
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 ISR. An example interrupt service routine called
vMAC_ISR() is provided in FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/webserver/emac.c. This should be used as a reference example.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
Switching between the pre-emptive and co-operative RTOS kernels
Set the definition configUSE_PREEMPTION within FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/FreeRTOSConfig.h to 1 to use pre-emption or 0
to use co-operative.
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-M3 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.