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
adapter_khz 30
jtag_nsrst_delay 100
jtag_ntrst_delay 100
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-microcontroller-using-eclipse-on-slackware/
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
reset run
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.
Comments
Direct use of Arduino code would be tricky for many reasons, firstly most of the current avr based arduinos have too little memory for running an RTOS (it's possible, but ideally you'd want more). If you're referring to running arduino code on a different platform, e.g stm32, then I'm sure you could write your own arduino library headers which translated between arduino -> chibios, but IMO that would be a waste as the Chibios API has all you need.
Thomas,
Is it possible to use ChibiOS/RT along with Arduino code?
STM32F4 can be programmed over USB using DFU-util on unix or ST's DfuSe demo. wiring it up for USB is much easier on the F4 compared to the F1, and can be brought into boot loader mode using BOOT0/BOOT1 pins during reset. I'm yet to get the JTAG to work on my F4 board, I probably messed something up on the PCB..
I'd strongly recommend trying out Chibios, the STM32F4 port is reasonably mature, and works great!
Hi Jack,
if you are interest to develop on STM32F4 you can use the VRIDE PRO a framework that we are yet develop to port the Arducopter32 from MP32F1 to MP32F4 .
This is the link : http://code.google.com/p/multipilot32/downloads/list
Best
Roberto
what is your mission, what u want to achieve ?