Marcy 2 was our most complicated layout, ever.  Manely, the camera had 20 connections.  Let it etch for 32 minutes to make sure all the .5mm pins were cleared.  There were a lot of photoresist flakes in the high res photo. 

Could use a smaller footprint.  Was a bit disappointed in how big the ARM was, compared to the one we used 5 years ago. ARM is also never going to be as cheap as an 8 bit microcontroller, because ARM charges a license fee.

  The chip we used 5 years ago had only 80 pins & never worked.

For programming an ARM, you're better off installing stmstudio in a Windows virtual machine & buying an stlink adaptor.  It would work just as well with our home made board.  Not sure why we're obsessed with doing it in Linux.

We must have memories of a younger age, when corporate bankruptcies caused us to lose many files.  We had a lot produced in GEOS, Speedscript, Microsoft Works, a cheap publishing program for DOS (Publish-it?), & none of it stayed readable.

The best way to program an ARM without buying a programmer is  Openocd

After banging on openocd for 2 days, trying to get it to work with the home made USB bit banger, we soldered a quick parport adaptor & it worked immediately.

The parport was faster than our USB bit banger & it worked.  Really wished the USB bit banger worked, since nothing on the bench still has a parallel port.

2 more days of hacking yielded a functioning USB JTAG interface.  The trick was level conversion using 120ohm resistors instead of 1k.  Also, the SDO pin needed a BJT level conversion.

Building Openocd was a matter of

configure --enable-dummy --enable-parport

then copying src/jtag/drivers/parport.c to src/jtag/drivers/marcy2.c

Edit marcy2.c to use the USB bit banger, then add marcy2.o under every parport.o in the Makefile.  Compile it with errors, then link it manually.

Run it with

openocd -f script

where script is a file in the current directory.  So far, our script has:

interface marcy2
#interface parport
#parport_cable marcy2
#parport_port 0


adapter_khz 30
jtag_nsrst_delay 100
jtag_ntrst_delay 100
jtag newtap marcy2 cpu -irlen 4 -expected-id 0x4ba00477
jtag newtap marcy2 bs -irlen 5 -expected-id 0x06413041


target create marcy2.cpu cortex_m3 -endian little -chain-position marcy2.cpu
marcy2.cpu configure -work-area-phys 0x20000000 -work-area-size 65536 -work-area-backup 0
flash bank marcy2.flash stm32f2x 0 0 0 0 marcy2.cpu




For us, that caused it to generate

Open On-Chip Debugger 0.5.0 (2012-03-04-19:49)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'marcy2' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
30 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
marcy2.cpu
Info : clock speed 30 kHz
Info : JTAG tap: marcy2.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: marcy2.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : marcy2.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: marcy2.cpu -- clearing lockup after double fault
Polling target failed, GDB will be halted. Polling again in 100ms
Polling succeeded again


For a new board, you need a script which just says

That causes it to probe for the TAPs & generate the jtag newtap commands, but it doesn't get the target running.

Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x4ba00477 ..."
Warn : AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x06413041 ..."
Warn : AUTO auto0.tap - use "... -irlen 4"
Warn : AUTO auto1.tap - use "... -irlen 5"
Warn : gdb services need one or more targets defined


Examples of openocd usage came from

http://fun-tech.se/stm32/OpenOCD/index.php

http://linuxfreak.pl/elektronika/debugging-stm32-cortex-m3-microcon...

http://gpio.kaltpost.de/?page_id=485



The next great task is programming the flash.  The only way to send debugging commands after openocd is initialized is

telnet localhost 4444

Key commands:

verify_image /amazon/root/vicacopter/arm/copter.bin 0x8000000

is supposed to calculate a CRC on the chip.  The standard testing procedure is

reset halt

There was some diabolical cut & paste from the STM32F4-Discovery & STM324xG-EVAL source code, some diabolical compiler scripts.

For the source files, we have

/opt/arm/bin/arm-elf-gcc -c -Iarm -Istm32f4 -mlittle-endian -mthumb -mcpu=cortex-m4 -ffreestanding -nostdlib -nostdinc

For the linking, we have

/opt/arm/bin/arm-elf-gcc -o arm/copter.elf arm/main.o stm32f4/startup_ARMCM4.o stm32f4/stm32f4xx_gpio.o stm32f4/stm32f4xx_rcc.o stm32f4/system_stm32f4xx.o -mlittle-endian -mthumb -mcpu=cortex-m4 -ffreestanding -nostdlib -nostdinc -Tstm32f4/ARMCMx.ld -L/opt/arm/lib/gcc/arm-elf/4.1.1/

To convert it into an image suitable for flashing, we have

/opt/arm/bin/arm-elf-objcopy -O binary arm/copter.elf arm/copter.bin

So after 5 years, our 1st toggling GPIO via home made ARM board came to life.  Programming it over the home made bit banger is too slow.  The CPU clock isn't running at the full 168Mhz.