Archive for category stm32

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

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.