LPC17xx ARM Cortex M3 Assembly Language Example

I cut the traces on the bottom of the board between the LPC-Link part of the board and the LPC1769 part of the board. Then, I soldered a 16-pin header (2x8, double row, 8 pins in each row) and shorted pins 1 and 2 together (3.3V) and shorted pins 15 and 16 together (ground) (or, just don't cut those two traces). Pins 1, 2, 15, and 16 provide a convenient place to pick up power and ground for the serial adapter. This header is labeled J4 on the board.

I also soldered a single-row 27-pin header on each edge of the LPC1769 side of the board to give easy access to the serial port pins and other pins. This header is labeled J6 on the board.

In order to use the chip's built-in serial bootloader, I wired a serial adapter to UART0 so I could program the flash with the lpc21isp flash utility. You can get such an adapter from SparkFun (http://www.sparkfun.com/). I built my own with two gates of a 4049 chip (a real 4049, not a 74HC4049, because we need it to run at 3.3 volts) and some resistors.

We use (parts of) the GNU toolchain, running on Linux (such as Ubuntu 10.04). In particular we need the GNU "binutils" package, which includes the ARM assembler and linker and some utilities to manipulate the output files. We do not need the C or C++ compiler.

This is a cross assembler. It runs on a PC (such as a typical desktop or laptop with an Intel CPU) but produces code for an ARM CPU.

If you don't have GNU binutils for the ARM installed, you can download my "Bundle of Tools" at http://pygmy.utoh.org/riscy/.

The GNU ARM assembler prefers to use the at-sign for comments. I prefer to use the semicolon for comments. So, I write the assembly language program using semicolons for comments then run the program through a preprocessor that converts semicolons to at-signs before feeding the program to the ARM assembler.

The preprocessor program is named preasm.tcl and is included in the tools bundle mentioned in the previous section. If you prefer, you can manually convert the semicolons to at-signs.

Here is the program source code (from the file named led-lpc17xx.asm).

;;; led-lpc17xx.asm
;;; written by Frank Sergeant
;;;    frank@pygmy.utoh.org
;;;    http://pygmy.utoh.org/riscy
;;; This program is in the public domain.  See http://pygmy.utoh.org/riscy/cortex/
;;; for notes about the program and how to assemble, link, and burn to flash.

;;; Blink the LED on the LPCXpresso LPC1769 ARM Cortex M3 board
;;; (or any LPC17xx ARM board with perhaps minor modifications).

;;; The LED on the Xpresso board is labeled LED2 and is just to the
;;; left of (inside of) J6-36.  It is connected to P0.22. The LED is
;;; on when P0.22 is high.
        
;;; Directives
        .thumb                  ; (same as saying '.code 16')
        .syntax unified

;;; Equates

        .equ LED_MASK, 0x00400000 ; i.e., bit 22
        
        .equ PINSEL0,  0x4002C000
        .equ PINSEL1,  0x4002C004

        .equ FIO0DIR,      0x2009C000 ; port direction, 0 (default) = input
        .equ FIO0MASK,     0x2009C010 ; port direction, 0 (default) = input
        .equ FIO0PIN,      0x2009C014
        .equ FIO0SET,      0x2009C018
        .equ FIO0CLR,      0x2009C01C
        
        .equ STACKINIT,   0x10004000

        ;.equ LEDDELAY,    800000
        .equ LEDDELAY,    300000

.section .text
        .org 0

;;; Vectors
vectors:
        .word STACKINIT         ; stack pointer value when stack is empty
        .word _start + 1        ; reset vector (manually adjust to odd for thumb)
        .word _nmi_handler + 1  ;
        .word _hard_fault  + 1  ;
        .word _memory_fault + 1 ;
        .word _bus_fault + 1    ;
        .word _usage_fault + 1  ;

_start:

        ldr r6, = PINSEL1
        ;; set P0.22 as a GPIO pin
        ;; P0.22 is controlled by bits 13:12 of PINSEL1
        ;; xxxx xxxx xxxx xxxx xx11 xxxx xxxx xxxx
        ;;    0    0    0    0    3    0    0    0

        ldr r0, [r6]
        bic r0, r0, # 0x00003000  ; clear bits 13:12 to force GPIO mode
        str r0, [r6]


        ;; set LED output pin (i.e. P0.22) as an output
        ldr r6, = FIO0DIR             ; for PORT0
        mov r0, # LED_MASK            ;  all inputs except for pin 22
        str r0, [r6]
        
        ;; r0 still contains LED_MASK 
        ldr r5, = FIO0CLR
        ldr r6, = FIO0SET

loop:
        str r0, [r5]            ; clear P0.22, turning off LED
        ldr r1, = LEDDELAY
delay1:
        subs r1, 1
        bne delay1

        str r0, [r6]            ; set P0.22, turning on LED
        ldr r1, = LEDDELAY
delay2:
        subs r1, 1
        bne delay2

        b loop                 ; continue forever

_dummy:                        ; if any int gets triggered, just hang in a loop
_nmi_handler:
_hard_fault:
_memory_fault:
_bus_fault:
_usage_fault:
        add r0, 1
        add r1, 1
        b _dummy

The goal for this program (other than blinking the LED) is to start with a very simple program. This lets us check out our toolchain, our flash utility and/or JTAG connector and software, and our mental model of how it all works without getting bogged down in unnecessary complexities. For example, we do not use subroutines. We only set up the hardware stack because the ARM Cortex loads the stack pointer automatically. We hard-code the output port configuration register (rather than setting just the bits we need for the LED pin). We do not alter the clock source or speed (we use the default internal 4 MHz clock). We just want something to run now !

The LPC1769 MCU uses the "Thumb-2" instruction set, not the "ARM" instruction set. Even though the .thumb directive is equivalent to the .code 16 directive, the processor is still a 32-bit processor.

We define some symbolic constants, including the initial stack value (STACKINIT) and the LED delay value (LEDDELAY). If, after getting the program to run, you would prefer to make the LED blink faster or slower, then change the value of LEDDELAY.

The program starts at address zero (0x0000 0000) with the vector table. Each vector table slot is 4 bytes long. The first entry is the initial value for the stack pointer. We use 0x1000 4000 for the initial stack value.

The second slot in the vector table holds the address where program execution will begin. In this case, it is at the label _start. Actually, we adjust the address slightly in the vector table by adding 1 to it to make it odd. This is required because, in Thumb mode, a value loaded into the program counter must have its least significant bit set. I suppose there is a way to avoid doing this by putting the vectors is a special section and giving the linker certain command options and/or using an assembler directive.

We fill in several more slots in the vector table for various exceptions. They all point to a loop at the end of the program. We do not expect any of these exceptions to be triggered, but if they are, the program will just hang in a loop, incrementing two registers (so we will have something to look at if we are tracing the program in a debugger).

The rest of the logic should be straightforward. We alternately write a "1" bit to the FIOCLR and the FIOSET registers to turn bit 22 of Port 0 on and off (to turn the LED off and on), killing time so the LED flashes at exactly the speed we like best (adjust LEDDELAY to your personal taste).

lpc17xx.ld

/* Simple linker script for the NXP LPC1769 ARM Cortex M3.  Link the text
   of the program into on-board flash and use on-board RAM for data and stack.
*/

SECTIONS
{
        /* interrupt vectors start at zero */
        . = 0x0;  /* start of flash */

        .text :  {  *(.text)   }

        /* constant data follows code but still in flash */
        .data :
        {
          *(.data)
          *(.rom)
        }

        /* internal RAM starts at 0x10000000 */
        . = 0x10000000;
        .ram : { *(.ram) }

        .bss :
        {
          *(.bss)
          *(.ram)
        }
}

openocdlpc17xx.cfg

# This file is for use with the LPCXpresso LPC1769 board.
# It is named openocdlpc17xx.cfg.  Run it this way:
#    $ openocd -f openocdlpc17xx.cfg

# This is the JTAG connector I use
source [find interface/olimex-jtag-tiny.cfg]

# This is close enough to the board I use
source [find target/lpc1768.cfg]

# tell gdb our flash memory map and enable flash programming
gdb_memory_map enable
gdb_flash_program enable

# Note, on the JTAG interface I wired up to the LPCXpresso board, the
# nTRST is not available.  Do we need to tell OpenOCD about that?

# I don't know whether the following would help or not
#reset_config srst_only

This note does not go into the details of using the GNU debugger (GDB) with this board and JTAG. If you manage to get a working JTAG/OpenOCD connection to your board, see the "Bonus section" of http://pygmy.utoh.org/riscy/cortex/led-stm32.html for some hints about setting up the GDB configuration files.

Although I found the "Program Flash" tool bar button, and could make it apparently go through the steps to burn led-lpc17xx.bin, it didn't seem to work. (Of course, if you try this after you cut the traces between the LPC-Link side and the LPC1769 side, you need to jumper them again. For example, solder a 2x8 header into J4 then use shorting blocks on all 8 pairs).

If you should get this working, and especially if you are then able to tell Code Red that led-lpc17xx.s is the source code file, and are then able to step through it in the Code Red debugger, please email me with full details as to how you did it.

After cutting the traces and installing the 2x8 header for J4, and soldering in the 2x27 header (well, two separate 1x17 headers) for J6, I wired up an adapter to the board for my Olimex USB-TINY JTAG adapter and tried working with it with OpenOCD.

I did succeed in dumping memory, but attempting to program the flash and/or to single step failed.

Here is how I wired my connector, showing where I picked up the JTAG signals.

                                         JTAG
                                       Top View
                          .--------------------------------.
                          |                                |
          (LPC J4-2) 3.3v | 1 Vref               Vtarget 2 | 3.3v
                          |                                |
                     n/c  | 3 NTRST                 GND  4 |
                          |                                |
              (LPC J4-10) | 5 TDI                   GND  6 |
                          |                                |
               (LPC J4-4) | 7 TMS                   GND  8 |
                          |                                |
               (LPC J4-6) | 9 TCK                   GND 10 |
                          |                                |
                     n/c  |11 RTCK                  GND 12 | 
                          |                                |
               (LPC J4-8) |13 TDO                   GND 14 | 
                          |                                |
              (LPC J4-12) |15 RST                   GND 16 | 
                          |                                |
                     n/c  |17 DBGRQ                 GND 18 | 
                          |                                |
                     n/c  |19 DBGACK                GND 20 | GND (LPC J4-16)
                          |                                |
                          `--------------------------------'

I didn't bother with any pull-ups or pull-downs, assuming the signals that needed that were already pulled up or down on the LPCXpresso board itself. That I was able to communicate through this adapter (the mdw command to dump memory) seems to support this assumption.

I understand the RTCK signal is not needed. I really wanted to connect the NTRST signal, which apparently comes from the LPC1769 chip's pin 100, but I could not find where the LPCXpresso board brought that signal out to any connector and I did not want to try soldering to the tiny pins of the LPC1769 chip.

If you find that NTRST/pin 100 is in fact accessible somewhere on the board, please tell me where.

If you are able to get "real" JTAG (as opposed to the proprietary Code Red version) working with this board, please tell me how you did it.

This is not necessarily a dead end. I did successfully program the flash so that the LED blinking program would run. I used this command

lpc21isp  -donotstart -verify -bin led-lpc17xx.bin  /dev/ttyS1 38400 4000

and it reported a verification failure. What I would like to know is whether the my particular LPC1769 chip does indeed have some bad flash (but not in places that would prevent the LED blinking program from running) or if the lpc21isp program (version 1.79) is failing to verify flash that in fact is programmed successfully.

An obvious experiment, which I have not tried yet, is to slow down the baudrate, using somethink like

lpc21isp  -donotstart -verify -bin led-lpc17xx.bin  /dev/ttyS1 1200 4000

So, if you use lpc21isp to program the flash in an LPCXpresso board, please email me to tell me how it worked for you.