[Gnuk-users] Bricked FST-01 running tip-of-tree gnuk

[Mike Tsao]

Paul, thank you. I cannot conclusively say your advice helped, but I did
what you said and now have a device that is back on 1.0.1 with PIN retry
counter : 3 3 3.

For future reference, this is what I did:

1. Shorted across C3 after verifying in the schematic that this _should_
ground NRES, overriding the built-in pullup. I am guessing that the purpose
of C3 is to start NRES grounded, then slowly rise (thanks to the pull-up)
to de-assert reset once the uC has jumped to the reset code. I'm no
hardware expert but that's my guess.

2. Ran ./tool/stlinkv2.py -u about 20 times with varying timings relative
to the short. Kept getting "Core does not halt, try API V2 halt.
ValueError('Status of core is not halt.', 128)"

3. Give up, go get coffee.

4. Come back and build https://github.com/texane/stlink/.

5. sudo build/Debug/st-flash reset and see something that's not an error!

st-flash 1.4.0-13-g1969148
2018-01-10T12:18:28 INFO common.c: Loading device parameters....
2018-01-10T12:18:28 INFO common.c: Device connected is: F1 Medium-density
device, id 0x20036410
2018-01-10T12:18:28 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash:
0x1904000 bytes (25616 KiB) in pages of 1024 bytes

6. Return to ./tool/stlinkv2.py -u:

ST-Link/V2 version info: 2 29 7
Change ST-Link/V2 mode 0001 -> 0001
Flash size: 25616KiB
CORE: 1ba01477, CHIP_ID: 20036410
Flash ROM read protection: ON
Option bytes: 03fffffe
Flash ROM read protection disabled.  Reset the board, now.
SUCCESS

7. Try ./tool/stlinkv2.py src/build/gnuk.bin (which I tried rebuilding
after git checkout -b release/1.0.1):

ST-Link/V2 version info: 2 29 7
Change ST-Link/V2 mode 0002 -> 0001
Status is 0081
Flash size: 128KiB
CORE: 1ba01477, CHIP_ID: 20036410
Flash ROM read protection: off
Option bytes: 00ff5aa5
SPI Flash ROM ID: bf254a
WRITE
TimeoutError(flash write)

8. Try that a few more times, then move to the texane version of the tool:

$ build/Debug/st-flash write ../gnuk/src/build/gnuk.bin 0x08000000
st-flash 1.4.0-13-g1969148
2018-01-10T12:22:29 INFO common.c: Loading device parameters....
2018-01-10T12:22:29 INFO common.c: Device connected is: F1 Medium-density
device, id 0x20036410
2018-01-10T12:22:29 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash:
0x20000 bytes (128 KiB) in pages of 1024 bytes
2018-01-10T12:22:29 INFO common.c: Ignoring 2044 bytes of 0xff at end of
file
2018-01-10T12:22:29 INFO common.c: Attempting to write 109572 (0x1ac04)
bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0801ac00 erased
2018-01-10T12:22:32 INFO common.c: Finished erasing 108 pages of 1024
(0x400) bytes
2018-01-10T12:22:32 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
core id
2018-01-10T12:22:32 INFO flash_loader.c: Successfully loaded flash loader
in sram
108/108 pages written
2018-01-10T12:22:36 INFO common.c: Starting verification of write complete
2018-01-10T12:22:37 INFO common.c: Flash written and verified! jolly good!

9. Verify I'm back in business:

$ gpg --card-status
Reader ...........: Free Software Initiative of Japan Gnuk
(FSIJ-1.2.7-87061942) 00 00
Application ID ...: D276000124010200FFFE870619420000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87061942
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

It's possible that in between steps 2 and 3 I actually had succeeded in
getting the device into a reset state; otherwise I'm not sure what changed
from last night. But if I get messed up again I now have steps to recover.
Thanks again!

On Wed, Jan 10, 2018 at 12:20 AM Paul Fertser <fercerpav at gmail.com> wrote:

> On Wed, Jan 10, 2018 at 11:14:11AM +0300, Paul Fertser wrote:
> > The most reliable way to obtain control over an stm32 with SWD is to
> > connect under reset
>
> I've checked FST-01 schematics and I see SRST is not brought out to
> any connector. But you can use tweezers on C3 to short it, then start
> openocd with connect_assert_srst option and then remove tweezers at
> about the right time (might take a few tries).
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20180110/976aea2c/attachment.html>