search

skuep / AIOC

Ham Radio All-in-one-Cable
MIT License
713 stars 56 forks source link

AIOC Firmware update: Device's firmware is corrupt. ( dfuERROR, status(10) ) #15

Closed MiM-TMassey closed 1 year ago

MiM-TMassey commented 1 year ago

Hello!

In preparation for that test firmware mentioned in https://github.com/skuep/AIOC/issues/11#issuecomment-1412453058 , I wanted to set up my system to update firmware. I ran into a potential error, so I thought I would confirm that everything is OK. (And maybe document this for future users.)

AIOC: v1.0 OS: Windows 10 x64 22H2 Zadig: v2.7 WinUSB: v6.1.7600.16385

Here is what I did to be able to download firmware:

No USB device was available in the drop-down (which is expected: the AIOC is not plugged in). I then shorted out the first and last "pin" (on my board, hole) along the edge of the USB-C connector and then plugged the USB cable back in. My computer made the "Inserted USB" sound, and "STM32 BOOTLOADER" appeared in the Zadig drop-down.

The command finished with "File downloaded successfully", but in the stream of messages I get the following: DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations A bit of Googling returns results that show that this can be expected (https://www.reddit.com/r/olkb/comments/zltavp/worrisome_dfu_message_when_flashing_planck/) but others indicate otherwise.

I continue on:

This time I get a newly-named device: All-In-One-Cable. I'm pretty sure it was not named that before, but I'm not certain -- I don't remember what it was called (TinyUSB maybe?) I also get new devices in my Device Manager: USB Serial Device (with a different COM port number) and USB Audio Device (instead of TinyUSB Device). The USB Audio Device does not have the name or settings I had previously given the AIOC devices in the Control Panel Sound window.

So it seems that the firmware did indeed download correctly. I then went into the Device Manager and deleted the now-unused devices (View/Show hidden devices to see unplugged devices), and Control Panel/Sound to rename and reconfigure the new devices. (I actually also removed the AIOC, deleted the newly created COM port and re-inserted it so that it would use the same COM port number as before.)

I then re-tested CHIRP and DireWolf. They both seem to work exactly as before -- good and bad. So the firmware seems to have been downloaded successfully.

While I'm wasting your time on non-issues, one other one: is there any way to rename the COM device that shows up in Device Manager. I know that it can be renamed -- I have four of them and literally every one of them is different -- but most are generic names that makes it hard to differentiate one from the other. I know you're simply allowing Windows to apply a generic USB driver; but in case you do have control over that, naming it "AIOC USB Serial Port" or such would be really helpful... :)

Thank you very much for your work on the AIOC. I really appreciate it. I will leave this issue open just to make sure that there isn't a problem I might not be aware of, but otherwise I do not need additional assistance. Feel free to close this issue at your convenience.

For completeness, here is all of the output from the dfu-util command:

dfu-util -a 0 -s 0x08000000 -D ..\Firmware\aioc-fw-1.0.0.bin
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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/

Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release
Deducing device DFU version from functional descriptor length
Cannot open DFU device 0a5c:217f found on devnum 1 (LIBUSB_ERROR_NOT_SUPPORTED)
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading element to address = 0x08000000, size = 37356
Erase           [=========================] 100%        37356 bytes
Erase    done.
Download        [=========================] 100%        37356 bytes
Download done.
File downloaded successfully
skuep commented 1 year ago

In preparation for that test firmware mentioned in #11 (comment) , I wanted to set up my system to update firmware. I ran into a potential error, so I thought I would confirm that everything is OK. (And maybe document this for future users.) ... The command finished with "File downloaded successfully", but in the stream of messages I get the following: DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations A bit of Googling returns results that show that this can be expected (https://www.reddit.com/r/olkb/comments/zltavp/worrisome_dfu_message_when_flashing_planck/) but others indicate otherwise.

Yeah, apparently this message is OK. I think it has to do with the STM32 implementation of DFU on the MCU is not 100% accurate.

This time I get a newly-named device: All-In-One-Cable. I'm pretty sure it was not named that before, but I'm not certain -- I don't remember what it was called (TinyUSB maybe?) I also get new devices in my Device Manager: USB Serial Device (with a different COM port number) and USB Audio Device (instead of TinyUSB Device). The USB Audio Device does not have the name or settings I had previously given the AIOC devices in the Control Panel Sound window.

Sorry! That is to be expected :-) We got a (somehwat) official USB VID/PID from www.pid.codes and I used the opportunity to rename all the devices (and add additional USB strings for the soundcard devices. And a unique USB serial number).

I then re-tested CHIRP and DireWolf. They both seem to work exactly as before -- good and bad. So the firmware seems to have been downloaded successfully.

That's good (and bad ;-)). I will see if I have some time this evening, but probably on the weekend.

While I'm wasting your time on non-issues, one other one: is there any way to rename the COM device that shows up in Device Manager. I know that it can be renamed -- I have four of them and literally every one of them is different -- but most are generic names that makes it hard to differentiate one from the other. I know you're simply allowing Windows to apply a generic USB driver; but in case you do have control over that, naming it "AIOC USB Serial Port" or such would be really helpful... :) Don't worry! Do you have an example/screenshot? From my long-gone past experience with Windows, all I could get is "COM Port XYZ". How did you name the other ones?

According to this, it is possible to change the name via a regedit entry. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy\<serial_number>\FriendlyName.

You can do me a favor and try out if this works for changing the COM Port name. If it does, we could try and add/change this string automatically using Microsoft OS Descriptors 2.0

Thank you very much for your work on the AIOC. I really appreciate it. I will leave this issue open just to make sure that there isn't a problem I might not be aware of, but otherwise I do not need additional assistance. Feel free to close this issue at your convenience.

You are very welcome. Keep the feedback coming.

MiM-TMassey commented 1 year ago

According to this, it is possible to change the name via a regedit entry. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy\\FriendlyName.

You can do me a favor and try out if this works for changing the COM Port name. If it does, we could try and add/change this string automatically using Microsoft OS Descriptors 2.0

I am not familiar with Microsoft OS Descriptors. I am familiar with the registry hack, but I've found it to be annoyingly fragile: seemingly at random the name reverts back to the original name. I'm not sure if it's related to possible updates or such, or just the fun of typical USB enumeration that creates a new instance if you so much as change ports -- with the original name and default settings, of course.

That's why my preference is to simply stick with the automatically-assigned names, but seeing as you asked nicely, I'll do it anyway, and I'll include some more details for future users.

I believe the registry path you included is incomplete. Because this is a multi-function USB target, there will be multiple entries in the Registry that will have the same VID and PID: we need the one that includes the MI (interface) parameter. It's easiest if you get the exact path you're looking for right from the entry in Device Manager.

Because of the serial number, this value should be unique. In my case, the path is: USB\VID_1209&PID_7388&MI_00\9&5DCDEE1&0&0000

(An aside: the FriendlyName parameter we need is visible here. Why couldn't Microsoft make it editable!?!)

Now let's change the cosmetic name:

For reference with other devices, if the FriendlyName value/data pair aren't there, you can add them. In this exact AIOC case it should be there, so if you think it isn't, make sure you've selected the right key! But for some other driver, you might need to add it.

Looks like I'm ready for new firmware! Thank you for following up. I will close this issue at this time.

skuep commented 1 year ago

Thanks for testing and finding out the details!

Using Microsoft OS Descriptors, we can push this registry entry from the AIOC to the Windows operating system. No need to do it yourself then.

Continuing here: https://github.com/skuep/AIOC/issues/16