ARM?? Cortex?? M4 Cookbook

Computer programming involves specifying a sequence of binary codes that are interpreted by the machine as instructions that together enable it to undertake some task. The instruction sets of early computers were small and easily memorized by programmers, so programs were written directly in machine code, and each instruction code word was set up on switches and written to memory. Finally, once all the instructions had been entered, the program was executed. With the development of more powerful machines and larger instruction sets, this approach became unworkable. This motivated the need to program in higher level (human understandable) languages that are translated into machine code by a special program called a compiler. Modern day programmers rarely need to interpret individual binary codes; instead, they use a text editor to enter a sequence of high-level language statements, a compiler to convert them into machine code, a linker to allow programs to reuse previously written (library) code, and a loader to write the binary codes to memory. The steps comprising edit, compile, link, load can be undertaken by running each program (editor, compiler, linker, loader) separately. However, nowadays they are usually packaged together within a wrapper called an IDE. Some IDEs are language-specific and some are customizable, allowing developers to create bespoke programming environments for any target language and/or machine.

The pack installer framework allows MDK-ARM uVision5 to be customized and extended to target a large number of devices and evaluation boards using ARM cores. But while, IDEs represent the most popular and efficient route to programming, uVision represents just one of a number of IDEs that are widely available. Other manufacturers and open source communities offer alternatives, some of which we investigate later in the book.

A USB-Link adaptor is needed to enable the executable code produced by the IDE to be uploaded to the evaluation board. The adaptor supports a Joint Test Action Group (JTAG) interface on the evaluation board, and offers a number of debugging possibilities (depending on the type of adaptor used). There are several debug adaptor connection options. Firstly, the Keil ULINK-ME debug adaptor (http://www.keil.com/ulinkme/), packaged together with the board as a starter kit, connects to the 20-pin JTAG connector and supports serial wire programming and on-chip debugging. Keil's ULINK-2 adaptor (http://www.keil.com/ulink2/) represents a more robust solution with similar functionality, and ULINK-Pro (http://www.keil.com/ulinkpro/) offers extended debug facilities employing high-speed streaming trace technology.

The MCBSTM32F400 (http://www.keil.com/mcbstm32f400/) evaluation board shown in the preceding image features the STMicroelectronics STM32F407IGHx microcontroller part. The board specification includes the following:

MCU manufacturers like Texas Instruments (TI), STMicroelectronics, Freescale, Atmel, Analog Devices, Silicon Labs, MikroElektronika, NXP, and Nordic Semiconductor all market evaluation boards featuring the Cortex-M4. Some of these offer cheaper, entry-level board options costing just a few dollars with functionality that can be enhanced by adding additional modules.

An insight into the range of microcontroller devices supported by MDK-ARM can be gained by scrolling through the list of packs listed by the Pack Installer. Keil markets a range of Cortex-M evaluation boards designed by themselves and other manufacturers (http://www.keil.com/boards/cortexm.asp) that feature a number of microcontrollers. Keil's range of boards features NXP, STMicroelectronics, and Freescale microcontrollers. The MCBSTM32 (Cortex-M3) and MCBSTM32F400 (Cortex-M4) evaluation boards offer one of the more expensive evaluation routes, but they are populated with a comprehensive set of I/O peripherals, including a QVGA TFT LCD touchscreen. STM (http://www.st.com) markets a similar evaluation board called the STM3241G-EVAL, offering almost identical features to Keil's but employing a slightly different PCB layout and using the STM32F417IG part.

Netduino (http://netduino.com/) offers a series of open source evaluation boards based on the STM32F405RG microcontroller featuring a Cortex-M4 core with open source software development support. Netduino is supported by an enthusiastic community of developers—a selection of projects which demonstrate the potential of the device are available.

Documentation for target devices and evaluation boards is available from the manufacturer. For example, those using the MCBSTM32F400 board will need to refer to the reference manual RM0090 (http://www.st.com), the MCBSTM32F200/400 User's Guide (http://www.keil.com), the ARM Cortex-M4 Processor Technical Reference Manual, and the Cortex-M4 Devices Generic User Guide (http://infocenter.arm.com).

You will also find that the schematic diagram of the evaluation board, at http://www.keil.com/mcbstm32f400/mcbstm32f400-schematics.pdf, is also useful for resolving ambiguities in the libraries. If you use MDK-ARM, then once a new project has been created and the target microcontroller identified, most of the relevant documentation can be accessed via the Books tab within the project window.

The program uses some advanced concepts such as CMSIS-RTOS (discussed in Chapter 8, Real-Time Embedded Systems.) to produce a visually interesting flashing LED pattern. We will not attempt to explain the code here, but the next section will develop a much simpler Blinky project called hello_blinky.uvprojx.

Those familiar with uVision4 will notice that the most obvious feature for of this program is that a call to SystemInit() is missing, as this code is executed before main() is called. The function called main() is the entry point for our program, and each project should declare only one file that defines a main function. Conventionally, this might be called main.c, or adopt a file name that is shared by the project such as helloBlinky.c.

The source code file begins with a large comment statement that extends over several lines and contains information about the program. Then there are C pre-processor directives; we discuss these in Chapter 2, C Language Programming. The program comprises a main function that declares two variables named i and num. There follows a function call to LED_Initialize() (written by developers) that sets up the GPIO peripheral which drives the LEDs. The program contains three so called for loops. The outer loop, is known as a superloop and never terminates. These statements within this loop are executed again and again, forever (well for as long as power is supplied to the evaluation board). The statements within the loop turn the specified LED ON and OFF by calling yet another function written by Keil developers. The other two for loops, nested within the superloop, simply waste time by incrementing the loop variable i. Implementing a delay in this way represents a very naïve approach, and we'll explore much more efficient techniques later. If you have not programmed in C before, then although you'll probably appreciate that this program is very compact, you may find it confusing. Don't worry, we'll revisit this program again when we introduce the C programming language in Chapter 2, C Language Programming.

The structure of the uVision MDK projects has evolved considerably over the past few years and uVision5 represents a significant revision in this respect. Developers of uVision5 have attempted to make microcontroller software development much simpler by providing library functions that can be used to control peripherals such as LEDs, accelerometers, touchscreen, and so on. Many application developers migrating from uVision4 find this burdensome, and favor more classic approaches that do not rely on intrinsic interface functions. Application programmers who wish to use their own middleware functions are advised to download the ARMs MDK legacy support pack (http://www2.keil.com/mdk5/legacy). The source files that, together with the project options, define the helloBlinky project are summarized in the following table:

A configuration wizard is provided to customize some files (for example, startup_stm32F40xx.s). However, we will deal with these more advanced aspects in subsequent chapters. Further, library and header file components, declared within the source files themselves, are also listed in the project window, and can be opened in the editor window. The file types you will encounter are described briefly in the following table, but will be discussed in more detail in Chapter 2, C Language Programming.

The project options are functionally grouped together. They are accessed through the tabs within the Project Options menu, and summarized in the following table. Further details are available in the uVision User Guide.

The options allow the developer to control quite small details of the build—for example, you might find it more convenient to execute code as soon as it is downloaded to the target by configuring the flash programming settings using the utilities tab as shown in the following image:

The STM32F400IGHx microcontroller implements 1MB On-chip Flash memory. RAM for Algorithm defines the address space used by the programming algorithm for the device.

To configure the GPIO follow the steps outlined:

The GPIO interface is a particularly important feature in microcontrollers because it is designed to be easily integrated within user systems to drive light emitting diodes, read the state of switches, or connect to other peripheral interface circuits. Early I/O ports were prewired to provide either output or input interfaces, but soon they evolved into general purpose interfaces that could be programmed to provide either output or input connections. Later devices included more programmable features. As GPIO is so important for microcontroller applications, designers are keen to specify as many I/O pins as possible on their devices. However, increasing the device pin-out adds cost because the device becomes physically larger to accommodate the pins. This motivates manufacturers to develop devices that have pins that are configured by software. As you can imagine, configuring such a device is quite a challenge, so we're lucky that Keil's developers have provided library functions that make this task more manageable. As GPIO represents the interface between hardware and software, the evaluation board's schematic (http://www.keil.com/mcbstm32f400/mcbstm32f400-schematics.pdf) is essential to understanding the I/O.

The STM microcontroller used by the evaluation board provides eight GPIO ports, named A-I. Port pins PG6,7,8; PH2,3,6,7; PI10 are connected to LEDs. Those who have never encountered an LED may imagine it as a filament lamp, but an LED is a semiconductor device and behaves slightly differently. However, sticking with our initial lamp analogy (for the time being), we'll first consider a battery-operated torch comprising a battery, switch, and lamp. These components are connected by a copper wire that is often hidden within the body of the torch. We'll assume that the torch uses two AA batteries providing a voltage of about 3 Volts. We can depict the circuit as a diagram with symbols representing each of the components, as shown in the following diagram:

When we close the switch, the battery voltage (denoted V) is applied directly to the lamp, a current flows (denoted I), heating the lamp filament, and this in turn, gives out light.

The electrical resistance (denoted R) of the filament determines the amount of current that flows according to Ohm's Law that is as follows:

Lamp filaments used in torches usually have a resistance of about 10 Ohms (10 Ω), so the amount of current flowing is about 0.3 A or 300 mA.

Imagine that a fault develops, which produces a short across the lamp. The current flowing is now only limited by the resistance of the copper wire and the internal resistance of the battery; these are both very small (a fraction of an Ohm). A high current will circulate which might, if the battery stored enough energy, cause the copper wire to heat up and melt the plastic case of the torch. However, AA batteries are unable to store sufficient energy for this to be a serious problem and in most cases the battery will discharge within a few seconds.

In modern torches, the lamp is replaced by an LED, which is a semiconductor device (its electrical properties lie between those of conductors, such as copper, and insulators, such as glass). An LED is a two terminal device with special properties. One of the terminals is known as the anode and the other as the cathode. If we replace the lamp in our torch with an LED, then current will only flow and the LED will illuminate when the anode is connected to the positive-battery terminal and the cathode to the negative-battery terminal, as depicted in the following diagram:

If we connect the device the other way round as depicted in the right side of the preceding diagram, then no current will flow; so, make sure that the batteries in your LED torch are fitted the right way round! When the anode is connected to the positive-battery terminal, the diode resistance is very low and the diode is said to be forward biased. When the cathode is connected to the positive-battery terminal the diode exhibits an extremely high resistance (negligible current flow) and the diode is said to be reversed biased. When forward biased, the LED exhibits an extremely low resistance, so an additional resistor must be placed in the circuit to limit the current flowing.

GPIO can also be used to read the state of switches that are connected to microcontroller pins. For this operation, each port bit must be configured as an input. When configured for input (that is, output is disabled), each bit of the parallel port's input data register is connected to a pin on the integrated circuit (on which the embedded processor is fabricated). Let's assume that we wish to connect a simple push-button switch to an input bit such that when the switch is operated, a voltage is applied to the port (pin), otherwise, no voltage is applied. The circuit a) shown as follows will achieve this. A complementary circuit that produces a voltage when the switch is open, and no voltage when the switch is operated (closed) is shown in b):

To eliminate the need for an additional resistor, the GPIO port input circuit includes one that can be configured by software as pull-up, pull-down, or disconnected. Obviously, when the port is configured as an output, both resistors are disconnected.

Section 7 of STMicroelectronics Reference manual RM0090 (www.st.com) for microcontrollers featuring the Cortex-M4 provides comprehensive programming details for the GPIO port. As well as producing logic signals (for example, making LEDs blink) and reading logic levels (for example, from switches), GPIO ports also provide an I/O path for other peripheral functions, such as Times and Digital-to-Analogue converters. We'll take a closer look at GPIO later on in this cookbook when we write programs that include more functionality.

To understand how the processor achieves this level of performance, we need to look at the processor architecture. The processor implements the ARMv7-M architecture profile described at http://infocenter.arm.com. ARMv7-M is a 32-bit architecture and the internal registers and data path are all 32-bit wide. ARMv7-M supports the Thumb Instruction Set Architecture (ISA) with Thumb-2 technology that includes both 16 and 32-bit instructions. ARM processors were originally inspired by Reduced Instruction Set Computing (RISC) architectures developed in the 1980s. RISC architecture attempted to improve on the performance of traditional computer architectures of the era that employed the so-called Complex Instruction Set Computing (CISC) architectures, by defining an ISA that supported a small number of instructions, each of which could be executed in one processor clock cycle, and so achieve a performance advantage. In the three decades since RISC was proposed, the size and complexity of RISC ISA's has increased, but the goal is still to minimize the number of clock cycles needed to execute each instruction. With this in mind, ARM Cortex-M3 and M4 processors have a three-stage instruction pipeline and Harvard bus architecture. Computers that use Harvard architecture have separate memories and busses for instructions and data rather than the shared memory systems used by von Neumann architectures, and the higher memory bandwidth this affords can achieve better performance.

The Cortex-M4 processor also provides signal processing support including a Single Instruction Multiple Data (SIMD) array processor and a fast Multiply Accumulator (MAC). Together with an optional Floating Point Unit (FPU), these features allow the Cortex-M4 to achieve much higher performance in Digital Signal Processing (DSP) applications than the earlier Cortex-M3.

Besides manufacturers' data sheets, there are a few books that address the Cortex-M4. Joseph Yiu's books (http://store.elsevier.com/Newnes/IMP_73/) on the Cortex-M3 and M4 processors are aimed at programmers, embedded product designers, and System-on-Chip (SoC) engineers. Books for undergraduate courses include a series of books by Jonathan Valvano (http://users.ece.utexas.edu/~valvano) and a text written by Daniel Lewis (http://catalogue.pearsoned.co.uk). Trevor Martin has also written an excellent guide to STM32 microcontrollers. This document is one of a number of insider guides that can be downloaded from http://www.hitex.com.