The chip seen just above the center of this image is an ARM Cortex-M3. It provides the ability to interface and program the main chip on the STM32F3 Discovery board. The protocol used is the ST-Link/V2 which has become the standard for ST Microelectronics development boards. The thing is, that big ARM chip near the bottom of the image has multiple UARTs and bridging a couple of solder points will connect it to the ST-Link hardware. [Taylor Killian] wanted to figure out if there is built-in firmware support to make this a USB-to-serial converter and his path to the solution involved reverse engineering the ST-Link/V2 firmware.
The first part of the challenge was to get his hands on a firmware image. When you download the firmware update package the image is not included as a discrete file. Instead he had to sniff the USB traffic during a firmware update. He managed to isolate the file and chase down the encryption technique which is being used. It’s a fun read to see how he did this, and we’re looking forward to learning what he can accomplish now that’s got the goods he was after.
[Matt Evans] took a closer look at the popular (and cheap) STM32F0 Discovery development board and realized he could get a second board out of the deal.
The Discovery board is designed to advertise ST Microntroller’s STM32F0 microchip; which with 8k RAM, 64K Flash, a bunch of peripherals, 48MHz clock, and a low price is a great chip. Though, they needed a way to program the STM32F0. To do this they added a second, more powerful, chip to the board as an interface. The STM32F103, with 20k RAM, 64K flash, and a 72MHz clock speed. [Matt] summoned genius, and simply sawed the board in half using a hacksaw.
Of course the caveat to all this is that you need a working Discovery board, or at least a working ST-LINK programmer, at the end of the day, to get any use out of your creation. Since the boards are so cheap though, it shouldn’t be a problem to buy two.
Last Wednesday I posted a video review of the new STM32F0-Discovery board which is built around an ARM Cortex-M0 chip. I speculated that it should work with the open source project aimed at programming these discovery boards. I tested it out and a connection could be made, but no code could be flashed. So I spent a few hours over the weekend and added support.
My updates are already in the stlink repository. After cloning the code, you can use three commands to compile the software (./autogen.sh, ./configure, make). That’s assuming you have all of the necessary dependencies (I had to install libusb-1.0-0-dev) and that you add the udev rule suggested in the documentation (also found in the repository). The program st-util connects to the board and provides a listening port for an ARM debugger (I’m using arm-none-eabi-gdb from CodeSourcery G++ Lite).
When I first started testing, the chip id was reporting as 0. It turns out the register address polled for this information was wrong. After finding that in the almost-900 page reference manual I went through the painstaking process of finding the hex values necessary to properly memory map the device. From there I also updated the blink example to generate an ELF file compatible with the Cortex-M0 chip. So out of the gate you should be able to use an ARM cross compiling toolchain to compile the example, connect to the board with this utility, then use the debugger from the toolchain to connect and flash that example to RAM.
There’s lots more to be done. To fully utilize the chip it is necessary to use a startup file and linker script when compiling. I’ve done nothing in this area, but I hope to work on some tutorials as I get further along. Of course if you have your own successes developing for this board using a Linux machine we want to hear about it!