STM32Mini


STM32Mini, just an ARM STM32 Cortex-M3 mini breakout board.

Features:

  • ready to run
  • minimal component count
  • 2.54mm "Square Pad Board" ready
  • USB support (disconnect optional)
  • on board battery
  • 20 pin ARM JTAG interface
  • serial, 3V3 logic interface for JTAGless programming
  • "programming" and "reset switch"
  • ...


Just a reconstruction from the original 2008 V1.0 version, whose documents were destroyed during a power supply burnout... Fit, form and function compatible ("almost").


Hardware

schematic
 layout
There is not much to say about this little project.
If you never heard of something like "STM32F10X", you probably won't need this...

Most of the pins are available on the two headers JP1 and JP2.
UART1 (MiniFTDI compatible), USB and JTAG (20 pin ARM) have their own connectors.

STM32Mini can be powered via USB or one of the headers. The JTAG header has a direct 3.3V connection, JP1 and JP2 are directly connected to USB+.
ATTENTION: Do NOT power STM32Mini from both ends, USB and one of the headers JP1 or JP2!

  • power from USB and use JP1, JP2 for powering attached hardware
  • power from JP1/2 (5V) if you DO NOT USE USB, only
  • power from JTAG header; requires regulated 3.3V

If you don't own any JTAG equipment, look out for Flash Loader Demonstrator (you may try this direct link). It will let you program the STM32 via a serial interface:

  • start Flash Loader Demonstrator and select your interface
  • remove STM32Mini's BOOT SRAM jumper, if present (JP3)
  • hold down STM32Mini's PROGRAM BUTTON (the one at the edge)
  • push and release STM32Mini's RESET BUTTON (the one near the header)
  • release the PROGRAM BUTTON
  • STM32Mini is now in system memory boot mode, ready to be programmed via UART1
  • In Flash Loader Demonstrator: click NEXT and follow the instructions
  • after programming, press STM32Mini's RESET button to execute FW (from flash memory)
Note: STM32Mini's UART connection of course requires 3V3 CMOS levels. Do NOT directly connect an RS-232!


Always attach an USB plug into the mini-B receptacle while soldering. Otherwise, the plastic parts will melt or be deformed afterwards.


Tools

Toolchains, JTAG, ...

For those who prefer a complete, "no guess" IDE, including a complete toolchain, etc..., it might be worth to give Raisonance's Ride7 and RKit-ARM a chance, here.

Others may prefer Code Sourcery G++ Lite Edition (and notice that Raisonance uses exactly the same, but packed in their, not that bad, Ride7 environment ;-)

Last but not least, Yagarto. I did not use it that much, but it comes with an ARM compiled Windows (MinGW) version of GDB, including Insight.

And JTAG? Well, there are hundreds of possible options. I am using a J-Link from Segger. Beside the full-featured, pricy equipment, they offer an educational J-Link version, for about 50 Euro, that comes with licences for:

  • debugging via GDB
  • flashing via GDB
  • flash breakpoints
Direct programming of flash memory is not possible, you need to make a detour via GDB. But reading and verifying memory is possible.

Tool's installation

I really like Ride7, so my main development machine is a Windoze XPee system. Unfortunately, GDB and all of it's frontends, are not natively available. As usual, Cygwin solves all of this problems at once ;)

The following suggestions or explanations require the following Windoze setup:

  • Ride7 or CodeSourcery G++
  • J-Link
  • Cygwin
  • Cygwin GDB for ARM
  • Cygwin DDD

Ride7

Install Ride7, from here:
  • IDE (Ride7)
  • ARM toolchain (RKit-ARM)
Make sure it's in the path:


in a Windows console, type (first line): 
					
  arm-none-eabi-gcc --version
	
  arm-none-eabi-gcc (Sourcery G++ Lite 2008q3-66) 4.3.2
  Copyright (C) 2008 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And notice the "Sourcery G++ Lite" ;-)
Having Ride7 and CodeSourcery G++ installed can indeed cause some confusion...

Quickly develop some interesting programs, now...

J-Link

Install J-Link from here.
Done...

Cygwin

Install Cygwin via it's setup.exe program.
If you never used Cygwin before, some of this hints may be helpful for selecting packages.

Additionally, you will need:

  • libXt-devel
  • libXm-devel
Most of the packages above will create other, additional dependencies. Just click YES...

If you're not familiar with Cygwin, come back in a month ;-)

GDB (Cygwin)

Download the newest source version of GDB, here.


unpack it in an appropriate place (e.g.: $HOME/install/gdb): 
					
  gzip -dc gdb-7.2.tar.gz | tar -xvf -


inside the unpacked dir, configure it by typing: 
					
  ./configure --target=arm-none-eabi


almost to the end of the configure output, there should be something like: 
	
  ...	
  checking for arm-none-eabi-cc... no
  checking for arm-none-eabi-gcc... arm-none-eabi-gcc
  checking for arm-none-eabi-c++... arm-none-eabi-c++
  checking for arm-none-eabi-gcc... arm-none-eabi-gcc
  checking for arm-none-eabi-gcj... no
  checking for arm-none-eabi-gfortran... no
  checking for arm-none-eabi-ar... arm-none-eabi-ar
  checking for arm-none-eabi-as... arm-none-eabi-as
  checking for arm-none-eabi-dlltool... no
  checking for arm-none-eabi-ld... arm-none-eabi-ld
  checking for arm-none-eabi-lipo... no
  checking for arm-none-eabi-nm... arm-none-eabi-nm
  checking for arm-none-eabi-objdump... arm-none-eabi-objdump
  checking for arm-none-eabi-ranlib... arm-none-eabi-ranlib
  checking for arm-none-eabi-strip... arm-none-eabi-strip
  ...

If the configure script did not find "arm-none-eabi-gcc", etc..., there's something wrong with your Windows path (which is inherited by Cygwin).


make it: 
					
  make

This should leave two binaries "GDB.EXE" and "GDBTUI.EXE" in the subordinated "gdb" directory.
Because a "Cygwin-targeted" GDB.EXE may already be present in your environment, but the new one you just compiled is for ARM, it may be wise to change the names of the two binaries to something containing "ARM"...


Do not use "make install"; copy these two by your own.
Inside the "gdb" dir, type: 
					
  cp gdb.exe /usr/local/bin/gdbarm.exe
  cp gdbtui.exe /usr/local/bin/gdbtuiarm.exe
  chmod 755 /usr/local/bin/gdb*


check target settings with: 
					
  gdbarm --version

  GNU gdb (GDB) 7.2
	...blablablabla...
  This GDB was configured as "--host=i686-pc-cygwin --target=arm-none-eabi".
	...blablablabla...

DDD (cygwin)

You don't need a special "ARM" version of DDD, a famous GDB frontend. The version that comes with Cygwin will be fine. Just add it via Cygwin's setup tool.

If you want the newest version (recommended), download it here. To avoid any confusion, remove any existing DDD package via Cygwin's setup.exe...

DDD compiles cleanly and usually does not need any special configuration.
Just unpack, configure, make and "make install" it...

Tool's usage

One of the drawbacks of using Cygwin is that it can not share native Windows paths and does not like spaces within them.

A Windows path like, e.g. "C:\kekse", has to be accessed as "/cygdrive/c/kekse", inside the Cygwin environment. Assuming Windows XP, your Ride7 work directory might be
c:\documents and settings\john john\programs\Ride7
with subordinated directories for single projects.

To overcome a lot of typing and problems that might arise from all that spaces in the path name, it's best to create a Windows batch file, which creates a new drive letter, granting direct access to your project directory.


Create a batch file inside the Ride7 work directory (e.g.: "CREATE_E.BAT"):

  subst e: c:\documents and settings\john john\programs\ride7

After doing so, you now have a new drive letter "E:" available, which offers a short access to your work dir. Note: Yes, also Ride7 (or CodeSourcery G++) can work in there!

From within Cygwin, this new drive is available as: /cygdrive/e


After some programming, connect your hardware to the J-Link and start the J-Link GDB server. It should find your JTAG interface, display its serial number and find a second device, a STM32F105RC in STM32Mini, in this case.

Inside Cygwin, preferably from an XTerm, change to your project directory and start your compiled "gdbarm".
Tip: Use Midnight Commander ("mc") to change the path without typing! Simply install it via the setup-tool.


As an example, a directory named "myproject": 

  cd /cygdrive/e/myproject
  gdbarm
	
  GNU gdb (GDB) 7.2
  ...blablabla...
  This GDB was configured as "--host=i686-pc-cygwin --target=arm-none-eabi".
  For bug reporting instructions, please see:
  http://www.gnu.org/software/gdb/bugs/.
  (gdb)


connect to J-LINK GDB server and change some settings.
Keep an eye on your J-LINK window... 

  (gdb) target remote localhost:2331
  Remote debugging using localhost:2331
  0x00000000 in ?? ()

  (gdb) monitor speed 2000
  JTAG speed set to 2000 kHz

  (gdb) monitor flash device = STM32F105RC
  Select flash device: STM32F105RC

  (gdb) monitor endian little
  Target endianess set to "little endian"

  (gdb) monitor flash breakpoints = 1
  Flash breakpoints enabled	

  (gdb) monitor flash download = 1
  Flash download enabled

Because all of the above will be required every time you start up GDB, it is wise to put this (and a little more [read on]) in a file named ".gdbinit", which has to be present in your Cygwin home directory.
All the commands in there will be executed sequentially, just like you would have entered them in the GDB console.


example, minimal .gdbinit file: 

  target remote localhost:2331
  monitor speed 2000
  monitor flash device = STM32F105RC
  monitor endian little
  monitor flash breakpoints = 1
  monitor flash download = 1

  ## programming:
  # load myproject.hex

  ## debug programming:
  # load myproject.elf

  ## load symbol tables (debugging):
  # file myproject.elf

  # not really required
  monitor reg r13 = (0x00000000)
  monitor reg pc = (0x00000004)

  monitor reset

Programming

After doing all of the above, you are ready to slam your firmware into the processor.


Now, program the flash memory (from a "hex" file):

  (gdb) load myhexfile.hex
  Loading section .sec1, size 0x10c lma 0x8000000
  Loading section .sec2, size 0xfef0 lma 0x8000110
  Loading section .sec3, size 0x10000 lma 0x8010000
  Loading section .sec4, size 0xbb14 lma 0x8020000
  Start address 0x8000110, load size 178960
  Transfer rate: 1456 KB/sec, 303 bytes/write.


Notice that you can do the same with an "elf" binary, for a debugging session
(which of course requires compilation with debug output): 

  (gdb) load myhexfile.elf
  Loading section .isr_vector, size 0x10c lma 0x8000000
  Loading section .text, size 0x2b4b0 lma 0x8000110
  Loading section .data, size 0x554 lma 0x802b5c0
  Start address 0x8000110, load size 178960
  Transfer rate: 1533 KB/sec, 303 bytes/write.

To start your program, type "cont" in the console (or just press the reset button).
Easy, right?

Debugging with GDB(TUI)


For a first debug-session, "gdbtuiarm" (or whatever you renamed "gdbtui" to) might be a wiser choice than just "gdbarm". Basically, it is the same, but it offers a source code display at the top.

You may wish to try a minimal Ride7 code debugging example, available in the download section. It does nothing else but put out a short pulse on PB5, and sending/receiving a string over UART1 (19200, 8N1). Just load this in Ride7's IDE, and build it. Do not worry about any "unable to find file" message. The IDE just tries to load the editor files from the last path seen (my "E:\TestSTM32"). This only will happen once...

Assuming you already created a .gdbinit file in your home directory:


Start "gdbtuiarm" and program the flash memory with "test.elf": 

  (gdb) load test.elf
  Loading section .isr_vector, size 0x10c lma 0x8000000
  Loading section .text, size 0xa5c lma 0x800010c
  Start address 0x800010c, load size 2920
  Transfer rate: 570 KB/sec, 292 bytes/write.


enter the following four commands: 

  (gdb) file test.elf
  A program is being debugged already.
  Are you sure you want to change the file? (y or n)  
  Reading symbols from /cygdrive/e/TestSTM32/test.elf...done.

  (gdb) break main.c:129
  Breakpoint 1 at 0x80002f6: file E:\TestSTM32\main.c, line 129.

  (gdb) monitor reset

  (gdb) cont
  Continuing.

  Breakpoint 1, main (argc=536936448, argv=0x0) at E:\TestSTM32\main.c:129
  (gdb)

  • file test.elf
    load debug symbol table

  • break main.c:129
    create a breakpoint in main.c, line 129

  • monitor reset
    reset the target

  • cont
    run target


now execute the line: 

  (gdb) next


The marker will advance to the next line. Hitting "ENTER" one more time, without entering something, repeats the last command, "NEXT", in this case.

Right now, the marker should point at:
"asSerialSendString("\r\nEnter some text: ");"


now execute the line: 

  (gdb) step


While "next" executes a single line of code, a "step" command will follow a function call. You now should be inside the function "asSerialSendString()".

To display the content(s) of a variable type: 



  (gdb) display *pdat
  1: *pdat = 0 '\000'

It's contents will be updated with every "next" or "step" command.
At this point, you should start reading the GDB manual.

Debugging with DDD


As a last, little example, start DDD, the Data Display Debugger. Because you renamed your "gdb.exe" to "gdbarm.exe", you need to tell DDD about that: 



  ddd --debugger gdbarm

If you are not sure about what version of GDB was started, type "show version" in the console at the bottom. The output should report your ARM-target "--target=arm-none-eabi".

Now, read the DDD manual.


Software

Software?
You now should be able to code, program and debug your own one ;)


Some Useless Pics

STM32Mini with MiniFTDI attached
 "no clean" (...)


Download

STM32Mini:

Includes:
- schematic (PDF)
- placement (PDF)
- layout, eagle (BRD)
- fishy BOM (TXT)
DOWNLOAD: stm32mini_hard_V12.zip HW; V1.2
DOWNLOAD: stm32mini_debug-example.zip minimal Ride7 code example from the debugging session above




ASkr 04/2008: initial public release (V1.0)
ASkr 03/2010: reconstruction (V1.1)
ASkr 07/2010: minor footprint changes (V1.2)
ASkr 10/2010: added J-Link, GDB, DDD stuff and some useless pictures