Error when trying to flash Nitrokey Pro 2 with SWD

Nitrokey Generic
#1

Hello everyone,

I want to flash the current v0.13 firmware to my Nitrokey with SWD. I never did something with SWD before and trying to learn as much as I can while figuring out how to flash the new firmware.

First of all I followed the README of the nitrokey-pro-firmware Repository.

But now I’m stuck with an error at the point “Reading MCU Flash” and don’t know how to continue from here. I hope some people can help me.

Here are the outputs:
openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg

Output 
    Open On-Chip Debugger 0.10.0
    Licensed under GNU GPL v2
    For bug reports, read
            http://openocd.org/doc/doxygen/bugs.html
    Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
    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
    none separate
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : clock speed 950 kHz
    Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.216284
    Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

openocd -f stm32read.cfg

Output 
    Open On-Chip Debugger 0.10.0
    Licensed under GNU GPL v2
    For bug reports, read
            http://openocd.org/doc/doxygen/bugs.html
    Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
    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
    none separate
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : Unable to match requested speed 1000 kHz, using 950 kHz
    Info : clock speed 950 kHz
    Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.229005
    Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
    Info : device id = 0x20036410
    Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
    Info : flash size = 128kbytes
    Error: error reading to flash at address 0x08000000 at offset 0x00000000
    Error: Read error
#2

It seems like the stick is broken now… :frowning_face:

The Nitrokey is no longer flashing red.
Error: init mode failed (unable to connect to the target)

#3

Hi!

Can you try the official tool described below?

I have not tested OpenOCD flashing lately, hence it was not covered in the latest README update.

In case you would like to run it anyway please let me know. Most probably it would be very similar to this, but with changed the configuration to interface/stlink-v2.cfg instead of interface/vsllink-swd.cfg:

#4

Do not worry - it’s not that easy to break it, unless you had used static electricity on it :slight_smile:

  1. Remember to re-power it, if the debugger is reporting it can’t make the connection.
  2. Flash read failed since all shipped devices have read protection activated. It can be removed with the debugger, but all data (including user ones) will be lost on it. When using in production, remember to activate it later as well.
  3. Final firmware consists of bootloader and application, with fixed start addresses. Flashing only the application part will work only, if the start address for it is set properly. See the devloop helper and DEVELOPMENT.md.
  4. Devloop is defined here:
#5

Thanks for all the information and the try to help. But there is no more reaction at all. What ever I did,
it does no longer work. :frowning_face:

#6

Can you paste your current error message?

#7

Of course :slight_smile:

Error: init mode failed (unable to connect to the target)

And dmesg says:

[10471.581451] usb 1-4.1: new full-speed USB device number 67 using xhci_hcd
[10471.709491] usb 1-4.1: device descriptor read/64, error -32
[10471.945498] usb 1-4.1: device descriptor read/64, error -32
[10472.185459] usb 1-4.1: new full-speed USB device number 68 using xhci_hcd
[10472.313497] usb 1-4.1: device descriptor read/64, error -32
[10472.549510] usb 1-4.1: device descriptor read/64, error -32
[10472.657963] usb 1-4-port1: attempt power cycle
[10474.189498] usb 1-4.1: new full-speed USB device number 69 using xhci_hcd
[10474.189687] usb 1-4.1: Device not responding to setup address.
[10474.397682] usb 1-4.1: Device not responding to setup address.
[10474.605502] usb 1-4.1: device not accepting address 69, error -71
[10474.733511] usb 1-4.1: new full-speed USB device number 70 using xhci_hcd
[10474.733701] usb 1-4.1: Device not responding to setup address.
[10474.941692] usb 1-4.1: Device not responding to setup address.
[10475.149513] usb 1-4.1: device not accepting address 70, error -71
[10475.149878] usb 1-4-port1: unable to enumerate USB device
#8
  1. Can you repower the debug adapter?
  2. How about the official flashing tool - the STM32 one?
  3. Check your SWD connections
  4. Just a sanity check, make sure you are using only one power source for the PCB under debug connection (either debugger or USB power).

Edit: dmesg messages may suggest, that the MCU flash got cleared and the device has no firmware on it anymore.

#9
  1. Can you repower the debug adapter?

dmesg outputs the following when I only plug the adapter:

Output 
[  155.720744] usb 1-4.2: new full-speed USB device number 12 using xhci_hcd
[  155.870683] usb 1-4.2: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[  155.870689] usb 1-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  155.870692] usb 1-4.2: Product: STM32 STLink
[  155.870695] usb 1-4.2: Manufacturer: STMicroelectronics
[  155.870698] usb 1-4.2: SerialNumber: 7ÿÿÿX078VsC
  1. How about the official flashing tool - the STM32 one?

I didn’t check yet. I need to check if there is a debian package for it.

  1. Check your SWD connections

I will resolder all the connections to make sure that everything is stable.

  1. Just a sanity check, make sure you are using only one power source for the PCB under debug connection (either debugger or USB power).

I only used the 5V power that is supplied by the adapter.

Thank you very much for trying to help me. :slight_smile:

#10
  1. Alright. In case you would lose your connection between debug adapter and the device, repowering of the former could help.
  2. Ok! I do not think there will be one, but please check. Regarding the OpenOCD, the latest one is v0.11, which could work better.
  3. You should be able to get away with just SWCLK and SWDIO, without the 5V and GND (though the latter is recommended).
  4. Alright. Please remember to disconnect the debug adapter when connecting to the USB, otherwise something bad can happen, depending on the debug adapter internal connections.

Happy to help! I just happen to have this fresh in the memory. I can do so only to some extent though, as this is not officially supported. And I am running out of the ideas too.

#11

I checked with the official tool, the output does not look promising.
Error: No STM32 target found

Even when I soldered all the connections again, there is no change.

I also checked for different combinations of cables. No chance to get it alive.

I really think it’s no longer working. I might have done a horrible mistake while
trying.

I think I’ll wait for my Nitrokey Pro 3A. Hope it will get shipped soon.

Thanks for all the effort. I really appreciate it. :slight_smile:

#12

Ah, shame. Maybe some other forum users would have any ideas how to debug that.

About the Nitrokey 3, we had an update lately:

Status Update, 8/25/2021
The development of the Nitrokey 3C NFC casing has been completed.
Planned delivery date for the PCBs is week 40. The subsequent assembly is planned with a few days.

#13

I have just reminded myself an idea. Last time I was debugging such connection problem I just run OpenOCD in a loop with a small delay, and powering the target device on and off, until it started working (it as well got locked for some reason back then). It was obviously a last resort method, but worked.