eBible on Cortex M0 with mbed

The eBible code has been ported from to use a Cortex M0 device and external flash chip.  The original chip used an M3 with lots of flash and SRAM, but this M0 part (NXP LPC1114FN28) has only 32Kbytes flash and 4Kbytes SRAM.

The challenge was to reduce and rewrite the functionality using less resources.  The M3 solution had used an SD card with FAT filesystem and had access to 512Kbytes flash and 64Kbytes SRAM.  All that was originally required was the bible.txt file on the SD, and the firmware would index all the books, chapters, and verses for navigation into multiple files on the SD card the first time it ran.  The M3 had no problem loading large sections of the text into memory to parse it into verses.  The M0 with its limited resources has less capability.

The M0 version does not use a file system, so the Bible text and index data are stored sequentially in flash storage (Spansion S25FL164K).  The index data structure is a sequence of structures for books, then intermixed with structures for chapters and verses.  The structures include text offsets, counts, and variable sized arrays pointing to other structures.  A fixed offset to the index structure, and bookmark structure is included in the code.  A separate firmware program for the M3 was written to convert the SD text and indexes and store them in flash.  This program was run once on the M3 to populate the flash chip, then the flash chip was moved to the M0 circuit.

Two different SPI circuits are present with one for the display and one for the flash.  The M0 chip used only has one SPI peripheral, so software SPI (bit banged) was implemented (ported from my C# implementation) to simulate another SPI peripheral.

A Text LCD wrapper library targeting Nokia 5110 was written to reduce the number of changes to the eBible source in porting from a text only lcd to the graphical Nokia 5110 lcd.

The remaining portions of the circuit to mention are the 3.3V voltage regulator (Microchip MCP1702), Nokia 5110 LCD display (purchased on eBay from a seller in Shenzhen, China), two switches, three blue LEDs, three AAA batteries, a battery holder, and some sockets.  A surface mount prototyping adapter board (SO8-50-EB) was used to attach the flash memory.  Two screws secure the battery holder to the circuit board.  The outside LEDs mirror the button presses, and the center LED flashes when bookmarks are changed when holding down both buttons.  Pressing the left button goes back one screen of text, and the right button advances to the next screen of text or next verse whichever comes first.  Holding down the buttons for a time navigates back or forward by multiple verses, chapters, or books depending on how long they are held down.  While navigating large sections of text, the book name, chapter number, and verse number are displayed, then switch back to the text after the buttons are released.

The parts chosen were primarily with consideration of cost.  The memory, display, and microcontroller are mbed online compiler and mbed library.  For debugging, the code was simply exported from the online compiler to Keil uVision 4 using a SeeedStudio Arch to act as the CMSIS-DAP debugger and programmer.  Being able to use a full-featured IDE including debugger for an mbed target is greatly appreciated.  Most of the work was done with the components in a breadboard, then transferred to a solder prototyping breadboard.  The result is a handheld electronic Bible that is smaller and more cost efficient that the originally developed version.

Schematic

mbedR3uino: mbed adapter for Arduino shields

The mbedR3uino is a vertical shield adapter for the mbed prototyping platform.  It provides compatibility with standard Arduino shields including the pins added to Arduino Uno R3 to make shields more independent between main boards.

This is the project I wanted three years ago.  Finally the need, inspiration, materials, and dependent projects converged.  The ability to easily add pluggable hardware to the mbed had been demonstrated when I created the In-between Shield for mbed which plugged into the mbed workshop board adding flash memory to the mbed which plugged into the shield. 

 

I have developed a number of prototype shields for Arduino using a ProtoShield that have been compatible with my various Arduinos, Netduinos, and other development boards providing plug compatibility with Arduino shields.  With the addition of the new R3 pins: SCL, SDA, IOREF some more platform independence has occurred allowing the shield (or at least its I/O) to run at the same voltage as the target platform, and a standardization of the location of the I2C pins.  The SPI pins which were originally reserved for ICSP or initial programming of the Arduino also became a standard.  I opted to skip the SPI/ICSP pin compatibility and stick with the Uno SPI pin layout for simplicity; a future version should include the SPI/ICSP pins in their expected location.  An R3 version of the ProtoShield was found here and I had seeedstudio build the PCBs.

The mbedR3uino is named because mbeduino was already taken.  Inserting the R3 in the name gives it some uniqueness while expressing its meaning.  The adapter consists of two pluggable pieces.  The first plugs into the workshop board above the mbed providing a footprint identical to the mbed.  Components were added to the ProtoShield to plug it into the first piece, and wire the connections to the Arduino R3 headers.  The result is that Arduino shields can be connected to the mbed.

Standard height 0.45" header pins were used to connect the ProtoShield to the above mbed adapter.  The above mbed adapter used taller 0.7" header pins so the PCB barely clears the height of the mbed, only touching the mini USB socket.  Since my prototyping boards have solder terminals only on one side, and to keep them clean looking I try to solder only on the bottom, hidden from view, I used needle nose pliers to push the pins so the plastic is flush with the top of the pins, and then carefully solder the pins from the bottom of the board not getting them too hot or the pin could waver out of place.  Once all the pins are soldered into place they hold very securely.

Note that the mbed workshop board or equivalent is required.  It already provides SD, Ethernet, and USB connectivity.  I have a revA board which pin 9 is held high to 3.3V (intended for SD card detect?), so to allow it to be used for the UART, I cut the trace on the workshop board.  An alternative to using the workshop board would be to have dual row headers and connect the columns for all pins 1-40, as done in my mbed Text LCD development board.  It is relatively easy to also solder a USB B connector, and an Arduino shield can be used for an SD card.  Connecting an Ethernet jack directly to the mbed can be done using a breakout board.

All the available pins on the mbed are either connected to the Arduino headers, or a few are broken out for additional expansion: since the workshop board already uses pins 5-8, they were left as an expansion; CAN and battery lines are implemented as jumpers for expansion.  Analog pins and power pins are where they should be, one UART is wired to D0/D1 for Arduino compatibility, and one SPI is wired for original Uno compatibility (D13-D10).  One pair of I2C pins are in the new R3 location, and the same pins are also wired to the same location as done with the Leonardo: D2/D3.  The remaining D14 and PWM pins are wired to the remaining Arduino header pins.  The schematic below shows how I chose to map the pins between the boards.

Schematic - Click on image to view larger

Getting started with OpenOCD

As referenced in my JTAG Adapter post the OpenOCD project is an open source JTAG program and set of drivers.  Professional JTAG programmers can commonly cost US $100 and up (some are thousands), and are often proprietary to a specific development toolset.  Open source and open hardware efforts have made JTAG available at much lower cost and at least works with open source development toolsets such as gcc/gdb and Eclipse, as well as some commercial offerings that are built on Eclipse.

Olimex has collected these open source development toolsets with OpenOCD and created a single installer called Olimex OpenOCD Development Suite for use with their development boards and their JTAG programmer.   Installing their suite is one of the easiest ways to get an ARM gcc toolchain installed on your system with an IDE and JTAG programmer.  Their toolset includes OpenOCD, Eclipse, gcc/gdb, and Zylin Embedded CDT.  Sample projects are provided for some of their Atmel, STM32, and NXP (LPC) boards.  I found that I needed to perform slight revisions their OpenOCD scripts included in at least the SAM7-P256-cdc_FLASH project because they were out of date.  Once that was done, I was using my JTAG adapter with their ARM7 board performing programming and debugging.  This suite and examples can be leveraged to target other boards. 

OpenOCD can also be used directly from the command line to make a connection with a board, and then use telnet to issue commands (see User's Guide) to direct it.  From the command line you can verify and discover commands to issue to your board.  In the following examples I will use my JTAG programmer to talk to the STM32F4Discovery board.  I have a breakout board for this development board that includes a JTAG socket.  I have disconnected the jumpers on the STM32F4Discovery for its onboard ST-LINK/V2 debugger, so I can use my JTAG programmer instead.

First you must have an interface script to talk to your JTAG programmer.  From the openocd-0.6.1 directory, I copied scripts/interface/ftdi/flossjtag.cfg to the file ft2232h.cfg in the current directory.  Then I commented out the ftdi_device_desc statement in that file, and appended
    adapter_khz 500
to the end of the file.

$ bin/openocd-0.6.1.exe -f ft2232h.cfg -f scripts/target/stm32f4x.cfg

Open On-Chip Debugger 0.6.1 (2012-10-07-10:34)
Licensed under GNU GPL v2
For bug reports, read    http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Then I open a telnet window to localhost port 4444.  From here I can issue various commands to OpenOCD to perform JTAG commands.

$ telnet localhost 4444

Open On-Chip Debugger
> reset halt
JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
> flash probe 0
device id = 0x10016413
flash size = 1024kbytes
device id = 0x10016413
flash size = 1024kbytes
flash 'stm32f2x' found at 0x08000000
> flash banks
#0 : stm32f4x.flash (stm32f2x) at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
> flash list
{name stm32f2x base 134217728 size 1048576 bus_width 0 chip_width 0}
> flash erase_check 0
successfully checked erase state
        #  0: 0x00000000 (0x4000 16kB) erased
        #  1: 0x00004000 (0x4000 16kB) erased
        #  2: 0x00008000 (0x4000 16kB) erased
        #  3: 0x0000c000 (0x4000 16kB) erased
        #  4: 0x00010000 (0x10000 64kB) erased
        #  5: 0x00020000 (0x20000 128kB) erased
        #  6: 0x00040000 (0x20000 128kB) erased
        #  7: 0x00060000 (0x20000 128kB) erased
        #  8: 0x00080000 (0x20000 128kB) erased
        #  9: 0x000a0000 (0x20000 128kB) erased
        # 10: 0x000c0000 (0x20000 128kB) erased
        # 11: 0x000e0000 (0x20000 128kB) erased
> dump_image image.bin 0x08000000 0x100000
dumped 1048576 bytes in 14.406221s (71.080 KiB/s)
> flash write_image erase stm32f4discovery_00.s19
auto erase enabled
wrote 1048576 bytes from file stm32f4discovery_00.s19 in 31.499985s (32.508 KiB/s)
> reset run
JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
> exit


^C

There you have it, some example OpenOCD commands.  Hope you learned something useful.

Hello World tutorial for STM32 Discovery boards using CooCox CoIDE and GCC ARM

ST Microelectronics has been supporting their Discovery line of ARM demonstration and development boards for a while now.  I was first introduced to the STM32 Value line discovery (STM32-F1), getting a free one at one of the embedded development conferences in San Jose or Santa Clara.  I had tucked it away for safe keeping (or hoarding), and over the years also acquired a STM32-F0, STM32-F4, and STM32-F3.  These are low cost (most $8-$11, with one at $15 US), and some of the more advanced boards include an accelerometer, gyroscope, or compass and multiple LEDs.

I recently stumbled across the CooCox CoIDE for working with the Simplecortex (I'll blog more about NXP chips and boards another time), and while starting to play with it, discovered that this IDE also supported the STM32 boards.  Which is great, as I had just started reading Discovering the STM32 Microcontroller by Geoffrey Brown of Indiana University and wanted to try my hand at developing for ARM in C.

As stated in their tagline, CooCox is a set of "Free and Open ARM Cortex MCU Development Tools."  CoIDE is an Eclipse based integrated development enviroment supporting the standard GCC ARM tool set: compiler, assembler, linker, and debugger.  The STM32 discovery boards include an embedded ST-LINK or ST-LINK/V2 which is supported by CoIDE for flashing and debugging.  The real value add by CoIDE is point and click choice of MCU library modules for various peripherals, with hypertext library references and examples.  CooCox supports a variety of ARM Cortex MCUs from various manufacturers.  ST is just one of the manufacturers.

Here I will show you how to install CoIDE and essential dependencies to develop a simple Hello World program for the STM32 Value line discovery board.  The steps are very similar for the other boards (except STM32-F3 is not directly supported at this time).  The program will display debug output from printf() through the ST-LINK to the IDE's console window.  This is the essential first program to see results from a program running on an embedded board.  And it's not just a blinking LED, though we'll do that too.

One time installation and configuration.

1. Download ARM GCC
2. Download CoIDE
3. Download STM32 ST-LINK Utility
3. Install ARM GCC
4. Install CoIDE
5. Configure CoIDE to point to ARM GCC
6. Install STM32 ST-LINK Utility
7. Plug in USB cable from PC to ST-LINK on discovery board

Creating your first project.

1. Click Create Project, name it hello
2. When prompted Chip or Board, choose Chip
3. Choose ST, and STM32F100RB.  Click Finish
4. In the Repository window, click on Semihosting and GPIO.  Required dependencies will autoselect
5. Double click on main.c in the Project window, and modify to contain

#include <stdio.h>
#include <stm32f10x_gpio.h>
#include <stm32f10x_rcc.h>

int main(void)
{
 GPIO_InitTypeDef gpio;
 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

 GPIO_StructInit(&gpio);
 gpio.GPIO_Pin = GPIO_Pin_9; // Green LED
 gpio.GPIO_Mode = GPIO_Mode_Out_PP;
 gpio.GPIO_Speed = GPIO_Speed_2MHz;
 GPIO_Init(GPIOC, &gpio);

 gpio.GPIO_Pin = GPIO_Pin_8; // Blue LED
 GPIO_Init(GPIOC, &gpio);

 printf("Hello World!\r\n");

 while(1)
 {
  static int count=0;
  static int i;
  static int led_state=0;

  for (i=0; i<1000000; ++i);
  GPIO_WriteBit(GPIOC, GPIO_Pin_9, led_state ? Bit_SET : Bit_RESET);
     led_state = !led_state;
     GPIO_WriteBit(GPIOC, GPIO_Pin_8, led_state ? Bit_SET : Bit_RESET);

  printf("%d\r\n", ++count);
 }
}

6. Open printf.c from the Project window
7. Add #include <semihosting.h> after the other includes.
8. In the PrintChar method, add the following line before the closing brace

SH_SendChar(c);

 

9. Right click on hello in tree of Project Window and choose Configuration

10. Navigate to Debugger tab, and verify ST-Link is chosen

11. Click on Semihosting Enable

12. Choose Project + Build, should be successful

13. Choose Debug + Debug, will deploy to board and stop at top of main

14. Choose Debug + Run to continue the program, should see output in Semihosting window