[Gnuk-users] Did I brick my fst-01?
NIIBE Yutaka
gniibe at fsij.org
Fri Feb 6 05:19:49 UTC 2015
On 02/06/2015 10:11 AM, NIIBE Yutaka wrote:
> Let's figure out next one. I'll try another connection of ST-Link/V2
> today. And I'll describe my experience with ST-Link/V2.
In the article of:
SWD connection to FST-01:
http://www.gniibe.org/memo/development/fst-01/dongle/fst-01-swd-connection.html
I wrote a figure::
CN3 of ST-Link/V2
1 2 [MCU VDD] RED ----->
3 4 [GND ] BLUE -----> Power port of FST-01
5 6
/--- BLACK [SWD-IO] 7 8
|/-- WHITE [SWDCLK] 9 10
|| ...
vv 19 20
SWD port of FST-01
Top View of FST-01:
WHITE BLACK
^ ^
| | SWD port (GND, SWD-CLK, SWD-IO)
Power port +---------------------+
RED <--- Vdd |[] []()() -------+
BLUE <--- GND |[] | |
|()() I/O port | USB |
| | |
| -------+
+---------------------+
... and this assumes that power to FST-01 comes from USB port.
Please note that The pin #2 of ST-Link/V2 is for a detection of MCU's
Vdd, it's not the source of power to the MCU.
Today, I tried a variant of connection, not connecting pin #2.
Following is the figure. Power comes from USB port. It connects
three pins between ST-Link/V2 and FST-01, killing the feature of MCU
Vdd detection.
CN3 of ST-Link/V2
1 2 [MCU VDD] RED----\
3 4 |
5 6 |
/--- BLACK [SWD-IO] 7 8 |
|/-- WHITE [SWDCLK] 9 10 |
|| ... |
vv 19 20 [GND ] BLUE -----> SWD port of FST-01
SWD port of FST-01 ^ |
| [Vdd] |
\---------------------/
Top View of FST-01:
WHITE
BLUE ^ BLACK
^ | ^
| | | SWD port (GND, SWD-CLK, SWD-IO)
Power port +---------------------+
|[] []()() -------+
|[] | |
|()() I/O port | USB |
| | |
| -------+
+---------------------+
Today, I use a 3-pin header like this for SWD port:
http://www.digikey.com/product-detail/en/961103-5604-AR/3M9468-ND/2071509
I don't solder the header to FST-01, but insert it with no solder,
and press it by my fingers. With single header pin, it's stable.
Here is the session log.
I tried to reproduce the problem. I began writing wrong firmware.
Because there was unprotected NeuG firmware on my FST-01, I used -b
option (to erase).
It successfully wrote the flash. Unplug/plug-ing FST-01, it resulted
failure of USB with the wrong firmware.
------------------------------------
gniibe at mini10:~/tmp/gnuk-fail-rsa4096$ ./tool/stlinkv2.py -b ./src/build/gnuk.bin
ST-Link/V2 version info: 2 21 4
Change ST-Link/V2 mode 0002 -> 0002
Status is 0081
CORE: 1ba01477, CHIP_ID: 20036410
Flash ROM read protection: off
Option bytes: ffff5aa5
Flash ROM blank check: False
SPI Flash ROM ID: bf254a
ERASE ALL
WRITE
VERIFY
PROTECT
Flash ROM read protection enabled. Reset the board to enable protection.
SUCCESS
gniibe at mini10:~/tmp/gnuk-fail-rsa4096$ dmesg
...
[16101.568276] usb 1-4.1: new full-speed USB device number 15 using ehci-pci
[16101.663284] usb 1-4.1: New USB device found, idVendor=0483, idProduct=3748
[16101.663303] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[16101.663315] usb 1-4.1: Product: STM32 STLink
[16101.663326] usb 1-4.1: Manufacturer: STMicroelectronics
[16101.663337] usb 1-4.1: SerialNumber: HÿkIgSW5"\xffffffc2\xffffff87
[16109.737752] usb 1-4.4: USB disconnect, device number 14
[16109.936278] usb 1-4.4: new full-speed USB device number 16 using ehci-pci
[16110.008306] usb 1-4.4: device descriptor read/64, error -32
[16110.184443] usb 1-4.4: device descriptor read/64, error -32
[16110.360611] usb 1-4.4: new full-speed USB device number 17 using ehci-pci
[16110.432278] usb 1-4.4: device descriptor read/64, error -32
[16110.608302] usb 1-4.4: device descriptor read/64, error -32
[16110.784290] usb 1-4.4: new full-speed USB device number 18 using ehci-pci
[16111.192076] usb 1-4.4: device not accepting address 18, error -32
[16111.264624] usb 1-4.4: new full-speed USB device number 19 using ehci-pci
[16111.672117] usb 1-4.4: device not accepting address 19, error -32
[16111.672279] usb 1-4-port4: unable to enumerate USB device
------------------------------------
Then, I unprotected the flash, unplug/plug, and wrote right firmware
(of 1.1.4).
------------------------------------
gniibe at mini10:~/tmp/gnuk-fail-rsa4096$ cd ../../work/gnuk/
gniibe at mini10:~/work/gnuk$ ./tool/stlinkv2.py -u
ST-Link/V2 version info: 2 21 4
Change ST-Link/V2 mode 0002 -> 0002
CORE: 1ba01477, CHIP_ID: 20036410
Flash ROM read protection: ON
Option bytes: 03fffffe
Flash ROM read protection disabled. Reset the board, now.
SUCCESS
gniibe at mini10:~/work/gnuk$ ./tool/stlinkv2.py ./src/build/gnuk.bin
ST-Link/V2 version info: 2 21 4
Change ST-Link/V2 mode 0002 -> 0002
CORE: 1ba01477, CHIP_ID: 20036410
Flash ROM read protection: off
Option bytes: ffff5aa5
SPI Flash ROM ID: bf254a
WRITE
VERIFY
PROTECT
Flash ROM read protection enabled. Reset the board to enable protection.
SUCCESS
gniibe at mini10:~/work/gnuk$ lsusb
Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader
Bus 001 Device 002: ID 174f:1403 Syntek Integrated Webcam
Bus 001 Device 036: ID 234b:0000
Bus 001 Device 015: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 001 Device 006: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
gniibe at mini10:~/work/gnuk$
------------------------------------
It works with lsusb.
The latter way of the connection is better for me about stability,
although it kills the feature of detecting MCU's Vdd (but, just
loopback-ing programmer's Vdd). I think that it's worth a try.
--
More information about the gnuk-users
mailing list