SWD interface disabled once Gnuk programmed?

NIIBE Yutaka gniibe at fsij.org
Wed Nov 21 06:02:50 CET 2018


The access can be protected against SWD interface (if you did so by
"stm32f1x lock 0" command of OpenOCD).  If not, it may be a problem of
sleep mode of the MCU.

Let me explain in detail.

Newer Gnuk (1.2.7 or later) supports USB suspend to minimize power
consumption.  When suspended (by no USB communication for a while), it
enters sleep mode of MCU.  When MCU is in sleep mode, I think that
ST-Link/V2 doesn't work well.

Patrick van Staveren <trick at vanstaveren.us> wrote:
> Is this by design? I assume it might be, to close this off as a vector of
> attack. Is there a way to open it back up? I don't mind losing the key I've
> generated on it as this is just experimental so far.

I think that you didn't connect and used your board to host PC when you
tried to access by OpenOCD.

Please connect it to host PC by USB, and do "gpg --card-status" (or
something equivalent), so that host PC runs scdaemon to access your
board.  Then, on your board, Gnuk is keep running, not in sleep mode.
In this condition, ST-Link/V2 must be able to access your board.

Even if it's protected, "stm32f1x unlock 0" command should work, which
unlock the SWD access erasing all flash.

Other information:

This problem can be solved when hardware and software support RESET
signal, to wake up MCU from sleep mode.  But FST-01 original and FST-01G
don't expose RESET signal to users, unfortunately.  Besides, support of
RESET signal by OpenOCD (and its drivers) is not in good shape, I
suppose.  Only some drivers with specific configuration can use RESET
signal.  I don't know how RESET signal can be used with ST-Link/V2.

(BTW, I support RESET signal by my patch of OpenOCD for BBG-SWD.)

More information about the Gnuk-users mailing list