DCC on the stm32-discovery

DCC or debug communication channel is a quick way to get debug output from a program running on a target device to the JTAG host device.  Unfortunately I found that the cortex-m3 doesn’t exactly have a DCC.

What it does have however is a general purpose data register (DCRDR) that gets used by the debugger for reading/writing registers, etc, etc, and  while there is no specification from ARM as to how to use it to accomplish something like DCC, it is possible and there’s already basic support for it in OpenOCD.

I ran into problems, however, getting all of my characters output.  It looks to me as if OpenOCD has a clever way of making the most out of the 32bit DCC register that makes use of all of the bits instead of just the lower 8 which is needed for basic single character DCC output.   For cortex-m3/DCRDR, it is necessary to use at least one bit for signalling between the target / host, so the OpenOCD code attempts to read 4 consecutive writes to build up a 32bit value.  One day, I may fully understand the 32bit format for the data and want to use it, but I’d like to have the simple single character output as well, so I made the following change to cortex_m3.c in the function cortex_m3_handle_target_request:

cortex_m3_dcc_read(swjdp, &data, &ctrl);

/* check if we have single char data */
if (ctrl & (1 << 1))
uint32_t request;

/* during this poll cycle read as much as we can from target */
while (ctrl & (1<<1))
request = data;
target_request(target, request);
cortex_m3_dcc_read(swjdp, &data, &ctrl);
if (ctrl & (1 << 0))

Then I’m using this code on the stm32:

volatile uint32_t *DCRDR = 0xe000edf8;

void DCC_write_byte(char cbyte)

static uint32_t waitCount = 0;

/* wait for host to read & clear value or timeout */
while (((*DCRDR)&0x1)&&(++waitCount<100000))

/* only reset the timeout if the value was read,
otherwise next time will immediately timeout (no host connected) */
if (((*DCRDR)&0x1)==0)


And this command to the rebuilt OpenOCD:

/usr/local/bin/openocd -d0 -f /usr/local/share/openocd/scripts/interface/vsllink-swd.cfg -f /usr/local/share/openocd/scripts/target/stm32vl.cfg -c init -c targets -c "target_request debugmsgs charmsg"

I don’t plan on submitting this to OpenOCD at this time since I’m using the version built from a script in the previous post, anxiously awaiting SWD support in a future release.

stm32-discovery and versaloon

The thought of having HW debug capabilities on a development board was fascinating, but I found out pretty quickly that I wouldn’t be able to accomplish everything I’d hoped with the ST-Link debugger which is included on the stm32-discovery.  I was searching for a cheap/open JTAG debugger when I stumbled across this thread on versaloon.com: http://www.versaloon.com/~bbs/viewtopic.php?f=2&t=17

Here’s how I accomplished converting the ST-Link of one stm32-discovery to Versaloon using the ST-Link of a second stm32-discovery to do the flashing.  The details are all pulled from the above linked thread; I’m not taking credit for any of this!  Many thanks to Bingo for the stm32-discovery patches and to Simon for the Versaloon project.  Another excellent side-effect is that you gain the ability to flash and debug from linux!

NOTE:  there will be no way to reverse back to st-link if you complete all of the following steps

1. Obtain the Versaloon binaries for the stm32-discovery.   You can find binaries (search for the most recent) attached to the thread or better you can build the binary from source.

2. I’ll be calling the stm32-discovery we’re updating to Versaloon the “target.”  You’ll need to solder two very thin wires to the target device.  I used wire-wrap wire for this.  This is the most difficult step; if you make it past here, you’ll be fine.

You’re going to solder to the left-hand side of the SB6 and SB10 bridges shown above, but you’ll want to be sure not to actually connect both sides of the bridge.  If you use too much solder, this may occur, and then you’ll probably need some solder wick to clean it up.  I found the easiest thing to do was to put just the tiniest bit of solder on the end of the wire, position the wire, and then attach to the pad.

As you can see, I attached a red wire to the SB6 pad and a yellow wire to the SB10 pad.  Nothing special, but hopefully it will help you to distinguish the two in this post.

3. I installed a 3 pin male header to the end of the two wires I just connected to the bottom of the board; this will make it easy to connect it to the host ST-Link.

4. Next I used F/F jumper wires to connect 5V/GND and SWD pins from the primary board to the target.  In the next couple of images, the target board is on top, the primary board is on bottom.

Above are 3 of the 4 connections on the primary board.  The jumper wires are connected on the primary board to the bottom 3 pins of the header labeled “SWD”.  The red and yellow jumper wires are connected to the red and yellow wires recently connected to the “target” board.  The black/center wire can be connected to any GND on the “target” board.  I’m using the one at the top right of the board.

The 4th connection is from a 5V pin on the primary board connected a 5V pin on the target.  In this picture the connection was made to the top-side of the board, but you’ll probably find it easier to connect to the bottom side.

5. Remove the jumpers from CN3 on the primary board.

6. Connect USB from a Windows PC to the USB port on the primary stm32-discovery board.

7. Run the ST-Link software.  Choose Target->Connect.  Then Target->Option Bytes and change Read Out Protection to Disabled.

8. Download the binary (.bin) you obtained in step 1 using Target -> Program & Verify.

9. Fix jumpers at CN3 on the target.  You’ll either need to make a “special” jumper out of a 4-pin female header or just jumper the center and run a wire between the outside posts.

10. Test newly programmed Versaloon with vsprog and openocd!

NOTE:  If you wish to use your newly converted versaloon stm32-discovery to program/debug a remote SWD target (like we used the “primary” stm32-discovery above), the SWD pins are now reversed.   This is explained in the versaloon forum linked above.


I’ve recently discovered the stm32-discovery board from STMicroelectronics thanks to someone at work.  It’s quite an impressive device (the STM32F100RB onboard, that is), but not as easy to use out of the box as an Arduino.


I bought two from mouser at $11 a piece….expect to see several upcoming posts related to this little board.

Arduino Equipment Security Shield

Sorry … it’s coming.

Sorry … it’s coming.

Avocent SwitchView IP 1010

First off, the boards I mentioned in the previous post come tomorrow, so if you’re lucky I may get in 3 posts in less than a week, but this is completely unrelated.

Some background …

Here’s the deal.  I recently got an Avocent SwitchView IP 1010 for less than $100.   Great deal.  The previous owner mentioned that it was missing a cable, but no real issue because that just meant that local access to the console/PC wouldn’t be available; accessing the PC over IP would of course still work and that’s what I wanted anyway… it turns out that was kind-of true; if you use the IP KVM with the vga+usb cable to the PC (which is what the PO supplied) you can access it over IP and all is well–if you are ok with providing mouse/keyboard to the PC via USB.   What I found tonight was that if you want to connect the PC to the KVM via PS/2, you need the “KVM cable that shipped with the unit” and had an end for connecting to the “Computer” port.

Cutting to the chase

Ok, so that was confusing.   If you happen to have this SwitchView unit and you’ve lost the cable that plugs into the “Computer” port and splits that output into the keyboard and mouse PS/2 inputs to the PC you’re connecting the KVM to, you know why this is a problem and this write-up is for you.

If you’re a fan of just getting the specifics and not getting any fancy details, look no further than the following table:


8-pin mini-din


Keyboard PS/2


Mouse PS/2


1 (kbd data) 1
2 (mouse GND) 3
3 (kbd clk) 5
4 (kbd +5V) 4
5 (mouse data) 1
6 (kbd GND) 3
7 (mouse clk) 5
8 (mouse +5V) 4

If you think I got pins 2 and 6 backwards, feel free to swap them, the GNDs are connected, so it’s no big deal.  If you read on, you’ll see why I picked them…but now that I’ve put them in the table like that, I’m tempted to change my mind as well.   FWIW, I just finished determining these connections about an hour ago and I haven’t tested a complete cable.  I’m missing the 8-pin mini-din (thought I had an old VGA card splitter cable that had the mini-din on it, but pins were connected somehow internally so it didn’t work) and so I’ve ordered 11 from jameco.com (part# 111878).  In the meantime, I took the PS/2 cable off of an old keyboard and poked the wires into the connector to setup the keyboard and mouse separately and (tested separately) both the mouse and keyboard work.  That said I’m 100% confident of the connections above, just waiting for the part to complete my own cable.

The details

Of course I opened up my SwitchView IP 1010.  Here’s a pic of the bottom, focused on the “Computer” connector:

First thing was to determine which of the pins in the group of 8 was connected to which pin in the connector.  The pattern is:

(5) (2) (1) (3)
(8) (7) (4) (6)

Next step was to figure out which pins could be determined using a continuity test. This revealed that pin 8 was connected to the +5V on the mouse PS/2 port and pin 4 was connected to the +5 on the keyboard PS/2 port. Pins 2 and 6 were found to be connected to GND.

(5) Gnd (1) (3)
Mou+5 (7) Kbd+5 Gnd

Flipping the board over, you can see the following pic:

Looking for a way to determine which of the remaining pins were clk and data, I noticed the 2 ICs directly above the connector.  Testing revealed that pins 7 and 3 were each connected to the right lower leg of one of these parts labeled KDA/P7.  I couldn’t find this part in a quick search, but it seemed to make since that perhaps this was a clock circuit?  Still not sure, but noticed 2 of the same KDA/P7s, 1 each, near the PS/2 ports.  In both cases, the right lower leg was connected to the clock line on the PS/2 ports.  That’s good enough for me, and leaves the remaining 2 pins as the data pins.  So now we have the following:

data Gnd data clk
Mou+5 clk Kbd+5 Gnd

I chose to believe the layout guy picked this arrangement and grouped the pins like so:









That would put the right group of 4 pins as the keyboard PS/2 connection and the left group of 4 pins as the mouse PS/2 connection.  After listing the pins in the table above, though, I think that the layout guy just got stuck with something that made sense numerically and I just got lucky because the grounds are connected!

Either way, this seems to test out.  I’ll try to remember to update the post once I get my 8pin mini-din and can test both the keyboard and mouse simultaneously, but I can’t see any reason why it wouldn’t work.  Since I’ll be cutting the PS/2 cables off of an old keyboard and mouse and the Jameco part costs $0.89 when purchased in Qty’s of 10, this cable will cost $0.89– assuming I can figure out a way to get my money out of the remaining 10 connectors I ordered.  I tend to over-order; the minimum $10 purchase and the cost of shipping gets me buying more than I need.  So to rephrase, the cable will cost me $10.

something in the works ..

ok, so it’s been awhile since my last post. I’m likely to say this many times, but I have great aspirations of blogging regularly and then it just never happens. I’ve started writing “Hard Drive Repair by Removing and Replacing the Head” and taken pics of many more of my HW repairs but just haven’t given myself the time to do the repairs and write about it. I repaired the master volume potentiometer on our Clavinova CLP100 last weekend using a similar part (not pin compatible, however) from Digikey and completely forgot to take any pictures, so that won’t be coming to this page, either.

Next week, however, I hope to have my first PCB back from the fine folks at BatchPCB.com (well, now, I haven’t seen my PCBs, so I might change my mind about them!)… and I intend to do a write-up on it.

I’ve got a few kids in the house and I use my garage as my “lab”. Most of the tools I’ve got are pretty safe, but I’ve got a few soldering irons and a heat gun that could be dangerous toys if they were to be used absent of any adult supervision. The PCB I’ve got coming is a shield for an Arduino that adds a 12-key keypad, dual 7-segment display, and connections for up to 4 125V/15A relays. I’ve got a first run of the code completed and what I’ll have when I put it all together is something much like the security control one of the big home improvement stores puts on their saws or bolt-cutters they use in-store.

I’ll post pics and an update when the stuff comes in. I may even have an extra board or two if all goes well.

Tags: , , , ,

Arduino and Asus wl520gu


I’ve been wanting to make my Arduino network accessible for awhile, now, and the idea of hacking a wireless-G router and loading some custom firmware like DDWRT was appealing. I happened upon a deal on an Asus wl520gu on craigslist ($20), so now the fun begins…

The Hardware

The wl520gu was acceptable for this hack, because it has solder points for a serial connection on its mainboard.  Step one, then, was making this serial connection available to connect to an Arduino.  The serial connections are 4 points in the empty space of the PCB.  I connected the bottom three (from the bottom: gnd, tx, rx).  The top connection is 3.3V, and since I wanted to run the Arduino off of the router power supply, I need 5V, which I pulled off the barrel connector at the bottom of the board.

pcb / bottom

After making all of the connections, I routed the wires out an opening in the bottom of the case and put it all back together.


… and connected 5V / GND from the wl520 to Vcc / GND on the Arduino and TX / RX from the wl520 to RX / TX on the Arduino.


Read the rest of this entry »