Thursday, February 20, 2014

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

Thursday, September 26, 2013

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

Saturday, September 7, 2013

3V-5V Switchable I2C Real Time Clock Shield

 
This is a prototyped Arduino shield that is 5V and 3V switchable.  The real time clock (RTC) is a DS1307 running at 5V, with a backup battery to keep time while not plugged into another power source.  It connects with an Arduino or similar board via I2C, but using a voltage translation (level shifter) circuit using FETs (reference: Philips) to isolate the RTC chip that always runs at 5V from the Arduino CPU which can be running at either 5V or 3V.  This provides support for 3V Arduino format boards such as the Arduino Due which can be damaged if 5V is applied to its lines.  Jumpers are provided to select the voltage (red), the I2C lines used (D3/D2 or A5/A4), and whether 3.3K pull-ups are used on the microcontroller side of the circuit.  Note the RTC always has its pull-ups in place.
 
Note that due to USPS regulations, Lithium batteries cannot (without meeting specific conditions) be shipped via US airmail so my Digi-Key order that included the FETs and crystal was revised to eliminate the batteries.  These are available cheap in bulk from many distributors, but to save immediate costs including shipping I ended up purchasing a single one at the local drug store.  Next time I may use ground shipping for such items, but I also found a local electronics supplier that has a decent price.
 
The DS3107 chip was purchased overseas via eBay as it was available much cheaper than domestically.  Hint: look for free shipping.
 
 
Schematic


A different 3V RTC chip could also be used, such as a surface mount chip, and then the level shifting circuit (FET drain/source) needs to be reversed per the original circuit recommended by Philips Semiconductors because the low/high sides of the circuit are reversed when the RTC is running at 3V and the microcontroller is running at 5V.
 
For prototyping the FETs ordered are in package TO92-3.  I ordered two different FETs and ended up using the more expensive ones with a higher Vdss rating (200V).  A cheaper FET in SOT-23 packaging with a lower rating of 50V was also sourced but not tested.
Adafruit has a tutorial including an Arduino library for use with the DS1307.  I tested this library on the Arduino Leonardo and Duemillanove running at 5V.  For the 3V Due, I used simple raw I2C (Wire library) commands to talk to the DS1307.  Only SCL1/SDA1 worked for me on the Due (had to jumper these as the ProtoShield is pre-R3 and doesn't have dedicated SCL/SDA pins).



(I had meant to publish this article in February but due to some bad soldering on my part and challenges with the Due, this prototype wasn't working properly.  Took multiple re-visits to fix everything.  Now I am very glad it is working now.)

Sunday, July 28, 2013

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.

Saturday, July 27, 2013

OpenOCD FT2232H based JTAG Adapter(s) with UART

USB to JTAG, and JTAG to JTAG adapters
JTAG adapters are commonly used to program and debug microcontrollers and microprocessors.  This circuit is a prototype of one that is compatible with OpenOCD which is an open source JTAG program and set of drivers.  The board and circuit presented here is simply a set of connections, jumpers, and sockets that leverage the FT2232H Mini Module as a USB to JTAG adapter. 

Four JTAG and/or SWD ports are provided for compatibility with a variety of development boards: 6-pin ST-LINK, 8-pin LPC-Link, 10-pin JTAG, 20-pin JTAG. 

Using one of two plug in modules, the 10-pin is either 0.05" pitch or 0.1" pitch. I plan to include both 10-pin formats on any revisions to this JTAG board so I can easily adapt between the formats.

When used as a USB JTAG adapter, only one of the JTAG or SWD ports is used.  Note that pin 1 is consistently in the upper left on this board.  Ribbon cables or socket cables are used to connect to the target board.  It is useful to have sets of cables that support all these pin-out formats.  Cables are quicker and easier than single conductor jumpers between individual connector pins.

An alternate use is to adapt from one pin-out to another when using other JTAG and/or SWD programmers.  In this case the mini module can be removed or simply disconnect the USB cable from the computer.  The board is only being used to convert pin-outs.  For example, I can use a 6-conductor socket to socket cable to connect the ST-LINK port to the ST-LINK socket on my STM32F4Discovery board, and then connect the LPC-Link socket via an appropriate cable to an LPCxpresso board.  I have used this method to program and debug my LPCxpresso board for LPC1343 with CooCox IDE.

Multiple JTAG adaptions are possible
  • ST-LINK to LPC-Link
  • ST-LINK to 10-pin
  • ST-LINK to 20-pin
  • LPC-Link to 10-pin
  • LPC-Link to 20-pin
  • 10-pin to 20-pin
  • 10-pin (1.27mm) to 10-pin (2.54mm) in future revision

Boards I was able to communicate with either with OpenOCD, ST-LINK, or CoLinkEx using the JTAG adapter(s) board include:

Caveats and Warnings.  Note that I did not do extensive testing.  I am not sure the RESET and RTCK lines are working.  Some boards I could only connect to using SWD instead of JTAG.  Driver installation and basic use of OpenOCD is not described in this post, so see Getting Started with OpenOCD.

Inspiration and References.  Most of the JTAG circuit is gleaned from multiple FTDI specifications regarding the FT2232H, Mini Module, and related MPSSE Basics Application Note AN_135.  And the circuit is very similar to the FLOSS-JTAG one shown here.


Under belly of the JTAG board
 

JTAG Schematic

Thursday, April 4, 2013

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









 


Sunday, January 20, 2013

USB RS-485 Adapter Through Hole PCBs Revisited

The second batch of through hole PCBs arrived recently.  I had fixed errors in the original design, moved some components around, corrected the silkscreen, and added silkscreen labels.  The design was uploaded to China, services paid for, and twelve PCBs were handed to me by the postal worker about four weeks later.

The worst offence of the original design was necessary green wire jumps and cuts rework for the Vcc and Vusb lines.  This new board doesn't require any rework.  I built up two boards and one works, and unfortunately I snipped a power line on the second board while trimming leads on a capacitor and some green wire solved the problem (oops, but good save!).

The silkscreen labels are a bit too small to see with my eyes, but make the board more usable.  I moved the JITE socket out so it hangs off the board with the benefit of the board also fitting screw terminals like those used in my (mostly) surface mount USB RS-485 Adapter board.