Programming the LM Cortex M3

I have tossed around a number of ideas on how to hook Ethernet to the SPOTs. The AT91RM9200 does have a built in Ethernet MAC and we did bring out the RMII interface with the intention of having Ethernet hooked up someday. The design needed an RMII PHY and 50MHz oscillator and we would have to adapt low level MAC drivers and integrate a TCP/IP stack.

I found an interesting option. When I was at the FIRST competition in Atlanta last April, I met with the Luminary Micro folks about their chips. What interested me the most was a low priced Cortex M3 (ARM) processor with built in Ethernet MAC-PHY. For example, the LM3S6432, a Cortex M3 50MHz processor has 96K Flash, 32K SRAM, 10/100 Ethernet MAC/PHY, 3-32 bit timers, SSI/SPI controller, I2C interface, 2-analog comparators, 2 UARTS, 3 channels of 10 bit ADC, 2 PWM outputs. It cost ~$10 through Digikey – a price comparable to my PHY solution. It has open source tools (gcc) and support for the open source lwip TCP/IP stack. When I got back from Atlanta, I got the RDK-S2E reference design kit and the LM3S6965 eval kit to try out. It is possible to hook these up to a SPOT; however, I don't have anything I can release to open-source at this time.

I thought this blog should be about my experience getting the open tools up and running.

Software Development

For this development, I'm using command line on Cygwin running on Windows XP (msys works just as well). Using eclipse and OpenOCD can be added once the tools and process are working.

The Luminary Micro processors are supported by the CodeSourcery, IAR, Keil, and Code Red software development kit (SDKs). These are commercial offerings with support, IDE, updates, etc. The eval board comes with a 30 day trial of one of these tools. CodeSourcery has downloads for the open tools and to get them go to website and take the products tab to Sourcery G++ -> Editions -> Lite -> ARM. Take the Download link and EABI link and download the appropriate package for your OS. It's a standard installer and unless you want the IDE, click on minimal install. This should have all the gcc compiler and utilities to make the project.

Next get the StellarisWare driver library: (requires free login account). Download and install either the individual device or complete firmware development package (~100Mbyte). I would also grab the LMFLashProgrammer utility.

The default install location is C:/StellarisWare. In this directory, the board specific demos are in boards. The driver API source and includes are in driverLib. The third-party folder contains two TCP/IP stacks, fatfs, and other utilities. They have low level device includes in the inc directory and useful source subroutines in the utils directory. There is a makefile at every level of folder leading to the project folders. The makefile at the root level (default is C:/StellarisWare) will make all projects for all boards The file makedefs in the root folder does most of the heavy lifting. This leaves the project makefile to do project specific naming, setting paths and dependencies. The makedefs file is included by the project makefile.

The eval boards use a FTDI USB to Serial IC configured as a JTAG programmer and serial port. It has the 20 pin JTAG connector for external programming of other boards but if nothing is plugged into this connector, JTAG will be directed to the processor on that board. JTAG does not require the on-board processor to be programmed. The eval board comes preprogrammed with a cute but eventually annoying game. It can be easily removed by erasing memory on the onboard CPU so you can JTAG in peace. Some of the reference designs boards need the 10pin to 20pin JTAG Adapter module (MDL-ADA2) and I understand it is included with the kits now. The adapter goes between a mini-JTAG 50mil spaced 2 x 5 connector and the standard 100mil 2 x 10 JTAG connector. If the JTAG isn't working properly, try plugging the eval board directly into the PC. FTDI chips have issues working over hubs.

The FTDI chip also has a serial port that is connected to UART0 on the processor. It's handy for debugging.

I created patch files and add-on makefile definitions that can be downloaded here. Unzip this in the top level of the StellarisWare directory. You can run the batch file ./patchstellaris to fix a couple of minor issues: There is a warning about type punning in lwip 1.3 and the fixes an excluded file name in the makefsfile utility in the 4781 release (Thumbs.db needs to be capitalized) .

There is also a makeaux which can be included either inside of makedefs file or in each of your makefiles after the include ${ROOT}/makedefs. makeaux adds "make program" which adds command line programming of the part with the target binary file. It adds "make prune" which moves (or removes) non-gcc files from a project out of the way to reduce clutter. It adds disassembly listing from objdump (.lss) and symbol table target (.sym) from nm. I have found these invaluable for debugging but don't need them all the time.

To create the disassembly and symbol files, add the line to your project makefile

all: ${COMPILER}/<targetname>.lss ${COMPILER}/<targetname>.sym


all: ${COMPILER}/<targetname>.axf

I didn't want to touch makedefs. My changes wouldn't keep up with future releases and I also wanted to keep the external changes to a minimum. "make program" works but will not do the correct build if the bin file is not there. Makedefs creates the binary file as a side effect and my preference would be to make the objcopy as a separate rule. This not only would fix the dependency issue, it would also print that bin file was made. The other nit is that if you are missing or misspell the .ld file it complains about standalone.ld missing and that is a misleading error. I couldn't find any other references to standalone.ld.

Luminary Micro went to some effort to output very succinct info while building rather than printing the multiline gcc command lines. This is very handy although you can turn it off setting the VERBOSE flag as:

make all VERBOSE=1

A small project

Other than the main c file, a project will need:

  • startup_gcc.c
  • <target>.ld
  • makefile

A good minimal example is blinky in the boards directory.

Edit and add my stuff to the blinky makefile. Type "make prune" to remove all non-gcc stuff to reduce the clutter.You should be left with the essential blinky files.

The startup_gcc.c file contains interrupt vectors, data segment initialization and BSS zero fill and call to main. This would be edited to change the interrupt vectors and change the default interrupt service routines.

The linker file (.ld) contains start address and length of the Flash memory and SRAM. If you are using a bootloader, edit the ld file so that the flash origin is 0x00001000. If you are running a standalone app, set this to 0x00000000. You may need to adjust the length as well.

make clean all

All resulting files including the binary will be placed in a gcc subdirectory. You can then run the LM Flash Programmer (or type make program) to program the device. To program over JTAG, you need to set the LM Flash Programmer configuration to Manual Configuration - JTAG FTDI Interface JTAG Speed 100000 and use the selected crystal value of 8.000MHz (for the eval board). From the program tab, select the bin file in the projects gcc directory and if standalone app, erase entire flash, verify and reset MCU with program address offset 0. Once programmed, Blinky will flash the status LED slowly. You should be in business to start exploring their libraries, examples and utilities.


I am going to be a software engineer.

Posted by jyoti prakash on September 15, 2009 at 05:25 PM PDT #

Hi Bob:
Thanks for the Blog. I will be following your path within the next few weeks and getting the command line build running. I hope I can figure it out as easily as you did.

Posted by Garry Anderson on April 07, 2010 at 06:07 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« June 2016