A self-contained GDB Server for AVR DebugWire on a $2 STLinkV2 dongle. It is loosely based on "Black Magic Probe" firmware.DebugWire is a proprietary hardware debugger interface available on some of the ATMega series. It is based on a half-duplex asynchronous serial protocol first documented here by RikusW back in 2011.
The DebugWire interface:
Note: There are no voltage translation logic in the cheap dongles, so the interface is only good for AVR part running at 3.3V - 5V.
How is this project different?
This work is loosely based on Black Magic Probe to create the firmware for a $2 standalone STLinkV2 clone dongle. The firmware implements a USB CDC ACM device, GDB server and DebugWire procotol. The dongle communicates directly with GDB over a USB virtual serial link.
There are no hardware to build. This does not relies on additional packages such as OpenOCD or Python or OS specific software like some of the other projects.
STLinkV2 Hardware
The generic STLink V2 clone is based on a STM32F103 or in some cases STM32F101. The dongle is a hardware debugger for ST ARM Cortex series (SWD) and their 8-bit STM8 (SWIM).
5V compatibility:
All the I/O signals on the STLinkV2 clones are hardwired to 3.3V. The I/O are TTL level compatible and 5V tolerant.
For the AVR /RESET pin functioning as DebugWire (i.e. I/O)
At Vcc = 5V, VIH3 = 5V x 0.6 = 3V (min) which can be satisfied by a 3.3V signal.
The signal I am interested in is SWIM_RST ("RST") which will be used as the DebugWire signal (/RESET).
The GPIO mapping shows that it is connected to both Timer 3 and USART1
The USART1 will be used in half-duplex mode with the pin configured as Open Drain which is compatible with DebugWire as is. PB5 will be configured as weak pull-up (input).
The Timer pin could be used to monitor the pulse width of the Break signal from the AVR to determine the communication speed.
There are other signals such as SWIM, SWCLK, SDIO on the dongle. They might be useful as a SPI programmer and/or wired for serial printf() at some future point.
Useful links
https://github.com/dcwbrown/dwire-debug - useful reference for implementing DebugWire commands
Tear down
I opened up my STLinkV2 clone and soldered to the SWD. The pads are specific to this PCB and may be different for your clone. Pin from Left to right: SWDIO, GND, SWCLK, +3.3V
The pads are 0.05" pitch which matches the spacing for a ribbon cable.
(I have traced the connections with my multimeter and looked up the datasheet.)
This is what the back side looks like. VUSB is routed directly to the 5V on the connector. There is a PTC fuse (F1) in the VUSB rail for 5-pin 3.3V regulator (U1) that powers the F101 and connected to the 3.3V pins on the connector. There seems to be a reasonable amount of decoupling caps on the regulator as well as the microcontroller.
22R series resistors (R1, R2) are used for the USB data pins, but populated a 1K pull-up (R3) vs the 1.5K specified by the USB standard! There are 22R series resistors (RP1) on the connector signals.
They are using a STM32F101CBT6 part in my STLinkV2 clone. They'll use the cheapest parts they can source for a production run, so don't expect the same parts or same PCB.
The F101 officially does not have USB device functional block. It turns out that there is SRAM at address 0x20000000 - 0x200004FFF which works out to 20KiB (instead of 16KiB). I don't have to worry too much trying to squeeze in the code/data size for testing.
Make that you have two STLinkV2 clones on your shopping list. You would need an additional STLinkV2 programming anyways. Do not update the dongle you want to use with STLinkV2 firmware as it might enable Read Protect.
SWD pinout for some of the clone variations: here
Unlocking Read Protect for STM32F10x
Seems like the STM32F101 chip is read protected because of DRM on the STLink firmware. This is probably because I updated it to their latest firmware as an initial test for the dongle. The read protect feature protects the FLASH memory outside of code access as well as write protects the first few blocks. A full chip erase does not disable the read protection in the option word as the unlocked values is not 0xFF by design.
Steps
1. Perform a Chip erase
2. Change the option byte
At this point a window will popup. Select "Disable" and hit "Apply"
After a progress bar, this warning popups.
3. "Disconnect" from target and then "Connect" again.
4. If you are not getting the following screen, you might have to repeat steps 2-3 one more time.
The read protect on the chip is now disabled!
What I did earlier trying to figure out the bootstrap mode. Don't bother with this unless you are looking for punishment.
I desoldered the chip to see if there are hidden connection.
Boot1 (PB2) is already shorted to GND on the PCB, so don't need to do anything.
Boot0 has a 10K (R5) pull down to GND. Pull this pin to 3.3V for serial bootstrap.
USART1 TX (PA9) is connected to the LED. It is accessible from the right pad of R9.
They could have made break out the USART1 RX with a test pad on the right side, but they didn't. You'll need to solder a fine wire to pin. So this is not the right way for anyone else.
I have decided to try something else and eventually got it working with the STLink Util. It wasn't mentioned in the first few google search pages. Who would have thought it was that simple!
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.