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

Wed Feb 4 06:27:25 UTC 2015

Thanks for the information.  I didn't know that we have newer OpenOCD
in experimental.

Sorry, I can't provide another instructions to recover in this
message.  This message is for your information.

The LED on FST-01 (blue) is controlled by the MCU, so, it only emits
light when MCU works and let LED emit light.  The tool/stlinkv2.py let
LED emit light by controlling the MCU.

In my case, the LED on ST-Link/V2 emit RED light when connected.  And
it seems it emits ORANGE on error (this is my own interpretation, which
might be wrong), and when successful invocation of commands, it's green.

On 02/04/2015 02:09 PM, micah wrote:
> When I do this, I either get an Error that the device cannot be reset,
> or an Error that init mode failed:
> 
> # openocd -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "init; reset halt; shutdown"
> Open On-Chip Debugger 0.9.0-dev-snapshot (2014-08-31-11:44)
> Licensed under GNU GPL v2
> For bug reports, read
> 	http://openocd.sourceforge.net/doc/doxygen/bugs.html
> jtag_ntrst_delay
> Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
> adapter speed: 1000 kHz
> adapter_nsrst_delay: 100
> Info : clock speed 1000 kHz
> Error: reset device failed
> in procedure 'init' 
> in procedure 'ocd_bouncer' 
> in procedure 'transport'
> in procedure 'init'

This time, we don't see the line of:

	Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748

... which is strange.  I think that there is some error (out of
synchronization in the protocol or something like that) between
ST-Link/V2 and host PC in this case.

> # openocd -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "init; reset halt; shutdown"
> Open On-Chip Debugger 0.9.0-dev-snapshot (2014-08-31-11:44)
> Licensed under GNU GPL v2
> For bug reports, read
> 	http://openocd.sourceforge.net/doc/doxygen/bugs.html
> jtag_ntrst_delay
> Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
> adapter speed: 1000 kHz
> adapter_nsrst_delay: 100
> Info : clock speed 1000 kHz
> Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
> Info : using stlink api v2
> Info : Target voltage: 3.535926
> Error: init mode failed
> in procedure 'init' 
> in procedure 'ocd_bouncer' 
> in procedure 'transport'
> in procedure 'init'

This case, it seems that communication between ST-Link/V2 and host PC
is good.  But it fails to initialize, in procedure 'init'.

For your information.  Here is a good example of mine with newer
OpenOCD:

===================================
$ openocd -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "init; reset halt; shutdown"
Open On-Chip Debugger 0.9.0-dev-snapshot (2014-08-31-11:44)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
jtag_ntrst_delay
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.172324
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
$
===================================

Here is another case, with somehow unstable connection, but succeeded.

===================================
Info : Target voltage: 3.170757
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Polling target stm32f1x.cpu succeeded again, trying to reexamine
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
===================================

>From here are failure cases with unstable connection.

Failure case #1:
===================================
Info : Target voltage: 2.938903
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: jtag status contains invalid mode value - communication failure
TARGET: stm32f1x.cpu - Not halted
in procedure 'reset'
===================================

Failure case #2:
===================================
Info : Target voltage: 3.172324
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 300ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
TARGET: stm32f1x.cpu - Not halted
in procedure 'reset'
===================================

Failure case #3:
===================================
Info : Target voltage: 3.173890
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 300ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
TARGET: stm32f1x.cpu - Not halted
in procedure 'reset'
===================================

Failure case #4:
===================================
Info : Target voltage: 3.170757
Error: init mode failed
in procedure 'init'
===================================

I think that failure in procedure 'init' means worse (not even
detecting the core), and failure in procedure 'reset' means better (it
detects the core).

Informational only:

I noticed that the firmware version of your ST-Link/V2 is version 17,
while mine is version 21.  But I don't think this is major problem,
since you successfully accessed FST-01 twice (unprotect with -u, and
writing new firmware).

Unfortunately, both versions are non-free software.  The upgrade is
available here.  It requires Windows to install:

    http://www.st.com/web/en/catalog/tools/PF258194
-- 