[Gnuk-users] Did I brick my fst-01?

Tue Feb 3 05:42:22 UTC 2015

I don't think your FST-01 is bricked.  I guess that you probably
flashed wrong image.

On 02/03/2015 12:00 PM, micah wrote:
> there must be better connectors that can be used for this!

I agree.  In future, when I will visit China, I will ask their
recommendation as a manufacturer on site.

> muck# ./tool/stlinkv2.py -u
> ST-Link/V2 version info: 2 17 4
> Change ST-Link/V2 mode 0100 -> 0001
> CORE: 1ba01477, CHIP_ID: 20036410
> Flash ROM read protection: ON
> Option bytes: 03fffffe
> Flash ROM read protection disabled.  Reset the board, now.
> SUCCESS
[...]
> muck# ./tool/stlinkv2.py src/build/gnuk.bin 
> ST-Link/V2 version info: 2 17 4
> Change ST-Link/V2 mode 0100 -> 0001
> 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

It looks no problem.

> I then unplugged everything and then plugged in the fst-01 alone, but no
> blue light and nothing in the journal, or in lsusb.

How did you build the gnuk.bin?

Most possible case would be some configuration error.  In Gnuk 1.0.x
and 1.1.n (0 <= n <= 3), default target is Olimex STM32 H103.  You
need to explicitly specify FST-01 for those versions.  Since Gnuk
1.1.4, its default is FST-01.

For users' convenience, Gnuk 1.0.4 binary for FST-01 is available here:

    https://gitorious.org/gnuk/binaries

> muck# ./tool/stlinkv2.py -s
> ST-Link/V2 version info: 2 17 4
> Change ST-Link/V2 mode 0100 -> 0001
> CORE: 00000000, CHIP_ID: 00000000
> Flash ROM read protection: off
> Option bytes: 00000000
> Core does not halt, try API V2 halt.
> ValueError('Status of core is not halt.', 128)
> 
> I quadruple checked the wires, and tried a number of different times,
> but I still receive the above message.

It seems that there were some connection error(s).  If not physical,
it would be protocol-wise.  But, in most of my cases, it was physical.

We should see something like:

	CORE: 1ba01477, CHIP_ID: 20036410

even if the core of MCU did not halt.  Under some unstable physical
connection, still, we could see like:

	CORE: 1ba01477, CHIP_ID: 00000000

I mean, it can detect the ID of core correctly.

If everything goes well, then, we see:

	Flash ROM read protection: ON
	Option bytes: 03fffffe

Then, ST-Link/V2 successfully let the core halt, it goes to send
commands of WRITE/VERIFY/etc.

> Is there anything that can be done, besides turn my fst-01 into some
> jewelry?

Stable wire connections.  That's important.

Another thing would be using OpenOCD.  stlinkv2.py is a work of
reverse engineering.  There are another independent work in OpenOCD.
If it's protocol thing which caused an error, another implementation
to access ST-Link/V2 helps.

I sometimes access FST-01 by ST-Link/V2 with OpenOCD.  Nowadays, it's
version is 0.8.0 (in Debian jessie).

Here is the session log of OpenOCD with unstable physical connection.

===========================
$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "init; reset halt; shutdown"
Open On-Chip Debugger 0.8.0 (2014-10-20-22:02)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.047718
Info : stm32f1x.cpu: hardware has 127 breakpoints, 0 watchpoints
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 300ms
Error: jtag status contains invalid mode value - communication failure
TARGET: stm32f1x.cpu - Not halted

in procedure 'reset'
$
===========================

It couldn't stop the core because of unstable physical connection.

Here is the session log of OpenOCD with stable physical connection.

===========================
$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "init; reset halt; shutdown"
Open On-Chip Debugger 0.8.0 (2014-10-20-22:02)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.938552
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000254 msp: 0x20005000
shutdown command invoked
===========================

It stops the core successfully.  I (wrongly) considered that it
reports higher voltage with stable connection and lower voltage with
with unstable connection, but it seems that it doesn't matter (and it's
not that acculate).

My wire (from ST-Link/V2 to FST-01) is currently 15cm long, but I
think that shorter is better.
-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20150203/5b77cc1c/attachment.sig>