Marcy 2 bringup

marcy2_13.jpg
 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. 


marcy2_12.jpg


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.

jtag03.jpg


  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


jtag08.jpg



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.

jtag09.jpg


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.

gcc -o openocd main.o ./.libs/libopenocd.a ../jimtcl/libjim.a -ldl /amazon/root/vicacopter/libusb-1.0.0/libusb/.libs/libusb-1.0.a  -lpthread -lrt


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

interface marcy2
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:

poll
reset run

reset halt

flash write_image erase /amazon/root/vicacopter/arm/copter.bin 0x8000000

That's very slow.  The USB bit banger is limited to the extremely slow 4000Hz.

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

flash write_image erase /amazon/root/vicacopter/arm/copter.bin 0x8000000
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.







E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

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!

  • Moderator

    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 ?

This reply was deleted.