<div dir="ltr">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.<div><br></div><div>For future reference, this is what I did:<div><br></div><div>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.</div><div><br></div><div>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)"</div><div><br></div><div>3. Give up, go get coffee.</div><div><br></div><div>4. Come back and build <a href="https://github.com/texane/stlink/">https://github.com/texane/stlink/</a>.</div><div><br></div><div>5. sudo build/Debug/st-flash reset and see something that's not an error!</div><div><br></div><div><div>st-flash 1.4.0-13-g1969148</div><div>2018-01-10T12:18:28 INFO common.c: Loading device parameters....</div><div>2018-01-10T12:18:28 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410</div><div>2018-01-10T12:18:28 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x1904000 bytes (25616 KiB) in pages of 1024 bytes</div></div><div><br></div><div>6. Return to ./tool/stlinkv2.py -u:</div><div><br></div><div>ST-Link/V2 version info: 2 29 7<br></div><div>Change ST-Link/V2 mode 0001 -> 0001</div><div>Flash size: 25616KiB</div><div>CORE: 1ba01477, CHIP_ID: 20036410</div><div>Flash ROM read protection: ON</div><div>Option bytes: 03fffffe</div><div>Flash ROM read protection disabled.  Reset the board, now.</div><div>SUCCESS</div><div><br></div><div>7. Try ./tool/stlinkv2.py src/build/gnuk.bin (which I tried rebuilding after git checkout -b release/1.0.1):</div><div><br></div><div><div>ST-Link/V2 version info: 2 29 7</div><div>Change ST-Link/V2 mode 0002 -> 0001</div><div>Status is 0081</div><div>Flash size: 128KiB</div><div>CORE: 1ba01477, CHIP_ID: 20036410</div><div>Flash ROM read protection: off</div><div>Option bytes: 00ff5aa5</div><div>SPI Flash ROM ID: bf254a</div><div>WRITE</div><div>TimeoutError(flash write)</div></div><div><br></div><div>8. Try that a few more times, then move to the texane version of the tool:</div><div><br></div><div><div>$ build/Debug/st-flash write ../gnuk/src/build/gnuk.bin 0x08000000</div><div>st-flash 1.4.0-13-g1969148</div><div>2018-01-10T12:22:29 INFO common.c: Loading device parameters....</div><div>2018-01-10T12:22:29 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410</div><div>2018-01-10T12:22:29 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes</div><div>2018-01-10T12:22:29 INFO common.c: Ignoring 2044 bytes of 0xff at end of file</div><div>2018-01-10T12:22:29 INFO common.c: Attempting to write 109572 (0x1ac04) bytes to stm32 address: 134217728 (0x8000000)</div><div>Flash page at addr: 0x0801ac00 erased</div><div>2018-01-10T12:22:32 INFO common.c: Finished erasing 108 pages of 1024 (0x400) bytes</div><div>2018-01-10T12:22:32 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id</div><div>2018-01-10T12:22:32 INFO flash_loader.c: Successfully loaded flash loader in sram</div><div>108/108 pages written</div><div>2018-01-10T12:22:36 INFO common.c: Starting verification of write complete</div><div>2018-01-10T12:22:37 INFO common.c: Flash written and verified! jolly good!</div><div><br></div><div>9. Verify I'm back in business:</div><div><br></div><div>$ gpg --card-status<br></div><div>Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.2.7-87061942) 00 00</div><div>Application ID ...: D276000124010200FFFE870619420000</div><div>Version ..........: 2.0</div><div>Manufacturer .....: unmanaged S/N range</div><div>Serial number ....: 87061942</div><div>Name of cardholder: [not set]</div><div>Language prefs ...: [not set]</div><div>Sex ..............: unspecified</div><div>URL of public key : [not set]</div><div>Login data .......: [not set]</div><div>Signature PIN ....: forced</div><div>Key attributes ...: rsa2048 rsa2048 rsa2048</div><div>Max. PIN lengths .: 127 127 127</div><div>PIN retry counter : 3 3 3</div><div>Signature counter : 0</div><div>Signature key ....: [none]</div><div>Encryption key....: [none]</div><div>Authentication key: [none]</div><div>General key info..: [none]</div></div><div><br></div><div>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!</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 10, 2018 at 12:20 AM Paul Fertser <<a href="mailto:fercerpav@gmail.com">fercerpav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jan 10, 2018 at 11:14:11AM +0300, Paul Fertser wrote:<br>
> The most reliable way to obtain control over an stm32 with SWD is to<br>
> connect under reset<br>
<br>
I've checked FST-01 schematics and I see SRST is not brought out to<br>
any connector. But you can use tweezers on C3 to short it, then start<br>
openocd with connect_assert_srst option and then remove tweezers at<br>
about the right time (might take a few tries).<br>
<br>
--<br>
Be free, use free (<a href="http://www.gnu.org/philosophy/free-sw.html" rel="noreferrer" target="_blank">http://www.gnu.org/philosophy/free-sw.html</a>) software!<br>
mailto:<a href="mailto:fercerpav@gmail.com" target="_blank">fercerpav@gmail.com</a><br>
</blockquote></div>