search

mercedes-benz / ardep

Software and Hardware Production Files of the Automotive Rapid DEvelopment Platform (ARDEP)
Apache License 2.0
3 stars 0 forks source link

Flashing the ardep "west ardep dfu" not working #3

Open AlexMicWalz opened 7 months ago

AlexMicWalz commented 7 months ago

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 commented 7 months ago

@ParaZera Any ideas?

ParaZera commented 7 months ago

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:

@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 commented 7 months ago

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 commented 7 months ago

Thanks for your input :smile:

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:

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.