Assembly-izing Tassel

Tass­sel: the extra ‘s’ is for “scat­ter­ing”

Work contin­ues on Corn­troller, my vaguely retarded version of Shane’s sweet brush­less motor controller.

I got my Digi-Key order last week and started assem­bling the board at the Graphics/Visualization/Usability (GVU) Proto­typ­ing Lab, the sister lab to the Geor­gia Tech Inven­tion Studio1, and home to my favorite hot-air reflow station on campus for proto­typ­ing.

Now the thing about reflow solder­ing is that it perfectly captures the sights, sounds, and smells of hell.

What else but hell would make you sit in place, hunched over for hours, as elec­tric fire brings tears to your eyes and solder paste brim­stone pierces your nostrils? Bright incan­des­cent light­ing, smol­der­ing solder­ing irons, and in the case of the GVU reflow station, a 50-deci­bel elec­tric pump all magnify the feel­ing of burn­ing alive in invid­i­ous flames of divine wrath.

But the GVU version of surface mount hell is actu­ally pretty legit. The afore­men­tioned elec­tric pump is hooked up to a preci­sion sole­noid valve gas dispenser (controlled by a foot pedal), which in turn feeds pres­sur­ized air into a hand-held tube of leaded solder paste. Hit the foot pedal, and a small and care­fully controlled bit of gray goop flows out.

The setup basi­cally lets you do manual pick and place assem­bly. Less effi­cient for small and medium runs than solder paste sten­cil­ing, but way less setup time and a lot more fun2. It’s perfect for proto­typ­ing a new board.

Now I ended up shoot­ing video instead of taking too many pictures, so bear with my video screen­shots here.

To make life easier, I assem­ble compo­nents under a 10×/30× stereo micro­scope with tweez­ers in one hand, solder paste dispenser in the other, and foot on the foot pedal.

At 10× you can see the parti­cles in the solder paste.

After assem­bly, I preheat the board over a Zephyrtron­ics… board preheater.

I’m not even making this up. This thing emulates the flat “warm-up” period of the reflow temper­a­ture profile you’d use in a full reflow oven. In addi­tion, it has a genius “cool” mode during which it draws air down (instead of blow­ing hot air up), using ambi­ent air to cool the board (“ramp-down”). No more blow­ing on the board until your face is red and your tongue is covered with flakes of solder.

It even comes with a sweet PCB jig to hold your board at just the right height above the pre-heater.

After that, you pretty much just apply heat like a normal person.

You may notice that in addi­tion to unpop­u­lated iner­tial sensors, there are also two funny-look­ing solder bridges.

You have ze Germans to blame for that. Had I the Euro­pean-styled schematic symbols für a common-mode choke ge-used, which had I the wrong orien­ta­tion for the part ge-using. I think.

In other words, I managed to short my input power leads across a pair of induc­tors.

Not that that surprises me in the least; I’ve managed to build almost every circuit I’ve ever designed to have a short from power to ground. Heck, this is the prob­a­bly the high­est imped­ance short I’ve gotten on a first-try board in the past two years.

Actu­ally, maybe the foot­print I was using for my Würth-Elek­tronik common-mode choke just had a mistake in pin assign­ments. But I like to chalk it up to cultural differ­ences, since it’s 34% more hilar­i­ous that way.

At any rate, I ended up skip­ping the choke completely using solder bridges; I get less noise immu­nity, but hey, nobody’s perfect and I’m not sure if it would’ve even helped at all.

At this point, it was time to try out the logic power supply. With fingers crossed, I hook up the bench power supply to the V+ and V- power pads and hit the switch.

Noth­ing.

Turns out when solder­ing leads to the V- pad while “e-test­ing” the board, I had broken one of the traces from the pad.

Oops.

I haven’t made a solder­ing boo-boo this bad in years, but what­ever. I briefly consid­ered running a little green wire over the trace3, but then real­ized that I tented over all my vias with solder­mask4 and couldn’t airwire even if I wanted to.

Instead I just ripped up the solder­mask with an X-acto knife under 30× magni­fi­ca­tion and then solder bridged the shorn copper. Like a boss.

Now I was getting a sweet 3.304V out of my LT3970 circuit from an input of 4V all the way up to 31V, which was as high as the power supply could go. Not really sure why this mattered, since I’ll always be putting 5V into the board, but what­ever.

But why the heck am I post­ing about such minor minu­tiae as fixing a broken trace when I should be plop­ping down code like a pro? Well, because perform­ing board bringup5 on an STM32-based board like this is an (neces­sary) act of distilled masochism, and I avoid it like a plague even when I’m already work­ing on the board to begin with. I mean, hell, the soft­ware you use with the popu­lar GCC/GDB ARM tool­chain is called OpenOCD.

So I plug my board into my Olimex ARM-USB-TINY-H and then pray to Tony Stark to guide my board to a success­ful JTAG inter­ro­ga­tion.

C:\Users\Xo>"C:\Program Files (x86)\OpenOCD-0.4.0\bin\openocd.exe" -f interface\olimex-arm-usb-tiny-h.cfg -f target\stm32.cfg
Open On-Chip Debugger 0.5.0-dev-00753-g422e9f9-dirty (2011-02-14-13:06)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : device: 6 "2232H"
Info : deviceID: 364511274
Info : SerialNumber: OLTQ5QMÖA
Info : Description: Olimex OpenOCD JTAG ARM-USB-TINY-H A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Warn : JTAG tap: stm32.bs       UNEXPECTED: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 1 of 5: 0x06412041 (mfg: 0x020, part: 0x6412, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 2 of 5: 0x06410041 (mfg: 0x020, part: 0x6410, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 3 of 5: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Error: JTAG tap: stm32.bs  expected 4 of 5: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 5 of 5: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints

“hard­ware has 6 break­points, 4 watch­points” is actu­ally what I expect to see, making this by far my most success­ful board bringup to date. But wait, what are those errors? Why isn’t my device (0x06430041) being recog­nized? Let’s take a look at the stm32.cfg script:

    # See STM Document RM0008
    # Section 29.6.2
    # Low density devices, Rev A
    set _BSTAPID1 0x06412041
    # Medium density devices, Rev A
    set _BSTAPID2 0x06410041
    # Medium density devices, Rev B and Rev Z
    set _BSTAPID3 0x16410041
    # High density devices, Rev A
    set _BSTAPID4 0x06414041
    # Connectivity line devices, Rev A and Rev Z
    set _BSTAPID5 0x06418041

Oops, my STM32F103VG XL-density micro­con­troller isn’t in there. The comments mention Section 29.6.2 of RM0008, the STM32F1x Family Refer­ence Manual. In section 31.6.2 (dotdot­dot) of the newest version of RM00086, we see that 0x06430041 is Revi­sion A of XL-density devices.

So I need a more recent version of OpenOCD that has the newer STM32 devices. Crap.

See, I use the default vanilla FTDI drivers for my Olimex, presum­ably so I can use the Virtual COM Port driver for the broken-out UART the ARM-USB-TINY-H doesn’t have. Yeah, I’m dumb. But OpenOCD doesn’t support those drivers out of the box; licens­ing issues prevent binary distrib­u­tors like Fred­die Chopin from making avail­able bina­ries compat­i­ble with regu­lar FTDI drivers. Instead most people use libftdi and libusb-win32 for hard­ware inter­fac­ing on Windows.

So I gotta build OpenOCD myself to make it work? God damn it; what is this, Linux?

Let’s just say $ ./configure --prefix=/cygdrive/c/Users/Xo/Desktop/ocd-build/out --enable-maintainer-mode --disable-werror --disable-shared --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/cygdrive/c/Users/Xo/Desktop/ocd-build/ftd2xx CC="gcc -mno-cygwin"7

With my new OpenOCD 0.6.0-dev build, I got a fully success­ful JTAG scan, and the OpenOCD GDB server is now open for busi­ness:

C:\Users\Xo>openocd -c "gdb_port 2222" -c "telnet_port 4444" -f "C:/Progra~2/OpenOCD/interface/olimex-arm-usb-tiny-h.cfg" -f "C:/Progra~2/OpenOCD/target/stm32f1x.cfg"
Open On-Chip Debugger 0.6.0-dev (2011-10-19-22:04)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : device: 6 "2232H"
Info : deviceID: 364511274
Info : SerialNumber: OLTQ5QMÖA
Info : Description: Olimex OpenOCD JTAG ARM-USB-TINY-H A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints

lol @ C:/Progra~2. Because this thing f—ing breaks if I don’t.

  1. At least in sweet, sweet fund­ing []
  2. No, not really []
  3. I hear in some Asian elec­tri­cal engi­neer­ing tria- circles, using more than 三 (3) little green wires is a shame to the engineer’s family and results in decapita- ritual de-accred­i­ta­tion []
  4. Yeah. On a first-version proto­type. Balls, suckas. []
  5. “Perform­ing board bringup” sounds way cooler than “bring­ing up” []
  6. As of 2011/10/19 []
  7. Yeah, that really is for my bene­fit only. How did you guess? []