Flashing the ardep "west ardep dfu" not working

[AlexMicWalz]

Hello,

on my Linux development notebook (Ubuntu 20.04), when I try to flash a newly built image to an ardep board, I consistently get the following error:

_

[4/8 9:53 PM] Walz, Alexander (059)
(ardep-ws-v1-TKMIL) alex@team-XPS-15-7590:~/Work/Workspaces/zephyr/ardep-ws/zephyr$ west ardep dfu

check if application needs to be rebuilt:

ninja: no work to do.

upgrading .

ERROR: dfu-util subprocess output:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2016 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature

dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

Opening DFU capable USB device...

ID 25e1:1b1e

Run-time device DFU version 0110

Claiming USB DFU Runtime Interface...

dfu-util: Cannot set alt interface zero

FATAL ERROR: Failed to upgrade ardep firmware on usb device 25e1:1b1e

dfu-util / Tickets

_

[f43i4n]

@ParaZera Any ideas?

[ParaZera]

I tried to recreate the issue with a new board without success.

I checked the west ardep dfu command and it should always try to write into alt interface 1, not 0.

@AlexMicWalz Can you provide the following information for further analysis:

• which commit are you on
• how did you try to update the board (via the west ardep dfu command?)
• the output of dfu-util -l when you plug in the board (without sudo rights)
• were you in bootloader mode when you tried to update

@AlexMicWalz can you try to update with the device with dfu-util itself. The commands are:

dfu-util --alt 1 --device 25e1:1b1e --download build/zephyr/zephyr.signed.bin
dfu-util --alt 1 --device 25e1:1b1e --detach 

[AlexMicWalz]

Yes, sure.

I tried to recreate the issue with a new board without success.

I checked the west ardep dfu command and it should always try to write into alt interface 1, not 0.

@AlexMicWalz Can you provide the following information for further analysis:

* which commit are you on

c765f3b (HEAD -> main, origin/main, origin/HEAD) doc: hardware schematics and sourcefiles (#51)

* how did you try to update the board (via the `west ardep dfu` command?)

Yes, I've used the command "west ardep dfu"

* the output of `dfu-util -l`  when you plug in the board (without sudo rights)

(ardep-ws-v1-TKMIL) alex@team-XPS-15-7590:~/Work/Workspaces/zephyr/ardep-ws/ardep$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

* were you in bootloader mode when you tried to update

no, was in normal mode

@AlexMicWalz can you try to update with the device with dfu-util itself. The commands are:

dfu-util --alt 1 --device 25e1:1b1e --download build/zephyr/zephyr.signed.bin
dfu-util --alt 1 --device 25e1:1b1e --detach 

Using the dfu-util directly, if no other programmer is connected, the download fails with:

(ardep-ws-v1-TKMIL) alex@team-XPS-15-7590:~/Work/Workspaces/zephyr/ardep-ws/ardep$ dfu-util --alt 1 --device 25e1:1b1e --download build/zephyr/zephyr.signed.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available

If there is a STLink programmer connected, the download fails with:

(ardep-ws-v1-TKMIL) alex@team-XPS-15-7590:~/Work/Workspaces/zephyr/ardep-ws/ardep$ dfu-util --alt 1 --device 25e1:1b1e --download build/zephyr/zephyr.signed.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 25e1:1b1e
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
dfu-util: Cannot set alt interface zero

[ParaZera]

Thanks for your input 😄

From the output of the dfu-util commands I deduce that it might be an issue with udev and access to the board.

Without installing our udev rule, I get similar output because dfu-util can't access the board and thus does not recognize it as a valid target.

The expected output of dfu-util -l would be:

❯ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found Runtime: [25e1:1b1e] ver=0305, devnum=15, cfg=1, intf=2, path="5-2.3.3.2", alt=0, name="UNKNOWN", serial="3131500D00550039"

To further analyze the issue, can you:

• verify, that the board is recognized as a usb device via lsusb with the correct vendor and product ID (25e1:1b1e)
• verify, that you installed the udev rule (See the getting-started-guide for more info)
• verify, that the udev-rule triggers when plugging the ARDEP board in

  udevadm control --log-priority=debug
  journalctl -f
  

  The output when plugging the device in should give you something like:

  Apr 26 08:05:49 Workiboy systemd-udevd[21838]: 5-2.3.3.2: /etc/udev/rules.d/99-ardep.rules:3 GROUP 46
  Apr 26 08:05:49 Workiboy systemd-udevd[21838]: 5-2.3.3.2: /etc/udev/rules.d/99-ardep.rules:3 MODE 0664
  
  Apr 26 08:05:49 Workiboy systemd-udevd[21838]: ttyACM0: /etc/udev/rules.d/99-ardep.rules:3 GROUP 46
  Apr 26 08:05:49 Workiboy systemd-udevd[21838]: ttyACM0: /etc/udev/rules.d/99-ardep.rules:3 MODE 0664
  

Regarding the behavior with a connected STLink programmer, I can't verify or reproduce the behavior, because I don't have such a probe. To be on the safe side, I would leave the programmer unplugged for now, so we have similar behavior when debugging the issue.

[AlexMicWalz]

I'm looking for help :-)

Thanks for your input 😄

From the output of the dfu-util commands I deduce that it might be an issue with udev and access to the board.

Without installing our udev rule, I get similar output because dfu-util can't access the board and thus does not recognize it as a valid target.

The expected output of dfu-util -l would be:

❯ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found Runtime: [25e1:1b1e] ver=0305, devnum=15, cfg=1, intf=2, path="5-2.3.3.2", alt=0, name="UNKNOWN", serial="3131500D00550039"

I have installed the udev-rule for ardep via "west ardep create-udev-rule"

To further analyze the issue, can you:

• verify, that the board is recognized as a usb device via lsusb with the correct vendor and product ID (25e1:1b1e)
  Strange. Board is not recognized when plugging it in via USB-C. But when I plug-in an STLink programmer at another USB-Port, then it is recognized and lsusb shows it correctly.

• verify, that you installed the udev rule (See the getting-started-guide for more info)
  yes, did that before.

• verify, that the udev-rule triggers when plugging the ARDEP board in

  udevadm control --log-priority=debug
  journalctl -f
  

No, journalctl shows nothing, so the board is definitely not recognized.
Is it possible that I've somehow overwritten the necessary bootloader on the ardep?
--> If so, I flashing a new bootloader to the ardep is either not working on my side, or I'm doing it wrong.

The output when plugging the device in should give you something like:

Apr 26 08:05:49 Workiboy systemd-udevd[21838]: 5-2.3.3.2: /etc/udev/rules.d/99-ardep.rules:3 GROUP 46
Apr 26 08:05:49 Workiboy systemd-udevd[21838]: 5-2.3.3.2: /etc/udev/rules.d/99-ardep.rules:3 MODE 0664

Apr 26 08:05:49 Workiboy systemd-udevd[21838]: ttyACM0: /etc/udev/rules.d/99-ardep.rules:3 GROUP 46
Apr 26 08:05:49 Workiboy systemd-udevd[21838]: ttyACM0: /etc/udev/rules.d/99-ardep.rules:3 MODE 0664

Regarding the behavior with a connected STLink programmer, I can't verify or reproduce the behavior, because I don't have such a probe. To be on the safe side, I would leave the programmer unplugged for now, so we have similar behavior when debugging the issue.

[ParaZera]

No, journalctl shows nothing, so the board is definitely not recognized.
Is it possible that I've somehow overwritten the necessary bootloader on the ardep?
--> If so, I flashing a new bootloader to the ardep is either not working on my side, or I'm doing it wrong.

The bootloader can only be overwritten with a debug probe connected to the SWD pins on the board because by default this partition is readonly when performing a DFU.

If you want to flash the bootloader again, please see the documentation, topic "Bootloader".

Do you have another board and/or pc to validate if it is an issue with this particular board and/or PC?

[AlexMicWalz]

No, journalctl shows nothing, so the board is definitely not recognized.
Is it possible that I've somehow overwritten the necessary bootloader on the ardep?
--> If so, I flashing a new bootloader to the ardep is either not working on my side, or I'm doing it wrong.

The bootloader can only be overwritten with a debug probe connected to the SWD pins on the board because by default this partition is readonly when performing a DFU.
As flashing via USB is not working workin on my notebook, I've indeed used a programmer to flash the board.
Also with a new bootloader.

If you want to flash the bootloader again, please see the documentation, topic "Bootloader".
yes,, followed these steps.

Do you have another board and/or pc to validate if it is an issue with this particular board and/or PC?
yes, I've tested today with another board, but same outcome.

[ParaZera]

Hey,
sorry for the late response.

Can you test the boards on a different PC? Getting no response from UDEV with several boards (with or without installed UDEV Rule) is rather suspicious.