updating older iRange4X that needs the usb related boot loader update

[timrowledge]

The instructions on updating the bootloader at https://github.com/benlye/flash-multi/blob/master/doc/New_Bootloader.md only refers to use of the Windows app for the job.

I don't have a Windows machine.

Assorted attempts to follow the rather wide range of different instructions have failed

• "load this to use unix" failed initially because the unix related pack assumes only x86 unix exists. This is not helpful if trying to use a Raspberry Pi.
• after trying on an x86 unix machine it seems the du-utils provided in the package is faulty in some way
• installing du-utils from the ubuntu repository worked better but not completely. For example the following -

 dfu-util -l -v
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/

libusb version 1.0.27 (11882)
dfu-util: Failed to retrieve language identifiers
dfu-util: Failed to retrieve language identifiers
dfu-util: Failed to retrieve language identifiers
dfu-util: Failed to retrieve language identifiers
dfu-util: Failed to retrieve language identifiers
dfu-util: Failed to retrieve language identifiers
Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="1-1.1", alt=2, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="1-1.1", alt=1, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="1-1.1", alt=0, name="UNKNOWN", serial="UNKNOWN"

This is very frustrating. I even found an explanation suggesting replacing the TX firmware with ErSky9 to update the module boot loader but that seems a bit extreme.

Advice & fixes would be appreciated

[benlye]

It's not documented, but the Linux folder includes a script called multi-bootreloader which you can use to write the new bootloader on Linux.

The script is fairly self-explanatory. But is also referenced in #48.

It's been a long, long time since I've tried to do this on Linux. I don't remember encountering any problems with the bundled tools. Did you follow the steps here to set the permissions?

[timrowledge]

Thanks for the rapid reply; much appreciated.

Yes, I ran the permissions & dev setting script with
sudo ./tools/install.sh
Just in case, I ran it again, with no changes in behaviour.

My first attempt with multi-bootreloader used the included dfu-util executable and failed like this -

./multi-bootreloader 
multi-bootreloader 0.2.0

This program is Free Software and has NO WARRANTY.
https://github.com/benlye/flash-multi/

The MULTI-Module firmware will be replaced by an application which will upgrade the module's bootloader.
Once begun, DO NOT interrupt the process, otherwise the bootloader will be corrupted and the module will not function.
If this happens a USB-to-serial (FTDI) adapter can be used to re-program the module.

The upgrade takes 4-5 seconds and will be complete once the LED goes off and remains off for at least 5 seconds.

Proceed with writing the BootReloader app? [Y]es or [N]o: y

Attempting USB upload using dfu-util

[1/1] Writing BootReloader app...
./tools/64bit/dfu-util -d 1eaf:0003 -a 2 -D "./tools/BootReloader_StickyDfu.bin" -R
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x1eaf product = 0x0003
Opening DFU capable USB device... ID 1eaf:0003
Run-time device DFU version 0110
Found DFU: [1eaf:0003] devnum=0, cfg=1, intf=0, alt=2, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Cannot set alternate interface

ERROR: Failed to write BootReloader!

I edited the script to use the repository loaded du-util mentioned previously, just in case, and got -

./multi-bootreloader 
multi-bootreloader 0.2.0

This program is Free Software and has NO WARRANTY.
https://github.com/benlye/flash-multi/

The MULTI-Module firmware will be replaced by an application which will upgrade the module's bootloader.
Once begun, DO NOT interrupt the process, otherwise the bootloader will be corrupted and the module will not function.
If this happens a USB-to-serial (FTDI) adapter can be used to re-program the module.

The upgrade takes 4-5 seconds and will be complete once the LED goes off and remains off for at least 5 seconds.

Proceed with writing the BootReloader app? [Y]es or [N]o: y

Attempting USB upload using dfu-util

[1/1] Writing BootReloader app...
/usr/bin/dfu-util -d 1eaf:0003 -a 2 -D "./tools/BootReloader_StickyDfu.bin" -R
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/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
dfu-util: Failed to retrieve language identifiers
dfu-util: Failed to retrieve language identifiers
Opening DFU capable USB device...
Device ID 1eaf:0003
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #2 ...
dfu-util: Cannot set alternate interface: LIBUSB_ERROR_OTHER

ERROR: Failed to write BootReloader!

As best I can tell at this point it seems something about my machine/module is failing to provide the name & serial data that assorted doc seems to expect. Does this indicate something wrong that can't be fixed; perhaps the current firmware is old enough that it just won't talk? The module was purchased in 2022 so it's not all that old really but who knows when it was manufactured and what firmware originally installed. The errors about dfu-util: Failed to retrieve language identifiers might indicate something? And presumably failing to set the alternate-doohickey is a problem too.

[benlye]

On Windows, this message would indicate a driver problem:

Found DFU: [1eaf:0003] devnum=0, cfg=1, intf=0, alt=2, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Cannot set alternate interface

Linux doesn't have drivers for the device, but your second error makes me think that there might be a libusb problem on your system:

Setting Alternate Interface #2 ...
dfu-util: Cannot set alternate interface: LIBUSB_ERROR_OTHER

If you unplug the device and plug it back in and then run lsusb, what's the output? You might need to use sudo lsusb.

What happens if you run the whole thing with sudo?
sudo ./multi-bootreloader

Have you got any other USB cables or USB ports you could try? If you're using a USB hub can you change to a direct connection?

[benlye]

I'm actually wondering if you even need to do this. The script output above indicates that the module is already in DFU mode when you run the script, which means you may already have the 'sticky DFU' bootloader.

Checking by plugging it in via USB:

• If the red LED blinks rapidly then starts to blink slowly and the green LED comes on you have the old bootloader
• If the red LED blinks rapidly continuously you have the new bootloader
• If the green LED comes on and the red LED stays off you have a module which does not use the bootloader for the USB port

[timrowledge]

Ah, slush (thank you autocockup, that should have been lsusb); I knew there was something else I should have checked. That actually results in
Bus 001 Device 009: ID 1eaf:0003 Leaflabs Maple DFU interface
so yeah, I guess your guess is about libusb night be correct. Thing is, this is a pretty recent Ubuntu (24.04).
Sadly, after (re)installing libusb (with the suggested sudo apt-get install libusb-1.0-0-dev) I see no changes.
On other suggestions, the LED flashing indicates old boot loader, and using sudo to run the bootreloader makes no difference.
As a last resort for today let's reboot the ubuntu-box. Dang, no change.

[timrowledge]

Just as a secondary sanity check I tried dfu-util --list, lsusb & multi-boot loader on my Pi 5. The results were just the same, implying that if anything is wrong with the libusb stuff it is pretty pervasive. I even tried everything with a different USB->miniUSB cable just in case. No luck. :-(

[benlye]

This doesn't really make any sense. If you have the older bootloader, you should not see the DFU interface once the module is running - you should see a serial port or nothing.

You say that the LEDs indicate that the module is running (green LED solid on), but you also have the DFU device all the time. Those two things cannot (should not) be possible at the same time.

How are you powering the module? If it's still in the radio, can you take it out and power it only via USB? Could you make a video? of the LEDs and the lsusb output?

[timrowledge]

Weird, isn't it?
I've never actually tried plugging the module into the USB while still in the TX because I assumed it might try to power the TX from the limited power of the USB. Experience with power hungry things and Raspberry Pis...
So when plugging in the USB the red led initially flashes rapidly and then as the green one lights up, red slows down. Right now it's sitting at green on solid and red flashing around 1Hz.
lsusb shows the same as before, du-util --list shows the same.

I could probably get my act together and try the Arduino IDE attack but that risks losing the opportunity to uncover and solve the unix issue, which seems sub-optimal. Sidestepping problems always seems like cheating to me.

[benlye]

There are two options I can see...

• Try to catch it while it's really in DFU mode (rapid red LED blinks), or
• Open the module up and use a USB-to-TTL adapter on the native STM32 TX/RX pins (may require soldering if the header pins are not there already).

Easiest thing to try first is catching the module while the red LED is rapidly blinking. You have to have the command ready to go in a terminal (in the path where you extracted the archive):
./tools/64bit/dfu-util -d 1eaf:0003 -a 2 -D "./tools/BootReloader_StickyDfu.bin" -R

And run it as soon as you plug the module in, while the red LED is blinking fast. It may take a couple of tries to get the timing right but it can be done.

If it works, give the module 5secs after the LEDs go out before you unplug it. After that you need to flash firmware to it as all it will have is the bootloader.

If that doesn't work, the foolproof way is to use the native STM32 TX/RX pins and a USB-to-TTL adapter to write directly to it. To be honest, you may end up here anyway. I don't have any doc covering how to wire that here, but the main project repo has plenty - https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Compiling_STM32.md#connect-the-module

[timrowledge]

I’m going to put this issue on the back burner for a week or two in order to avoid destroying my module when it is indoor flying time. Also got a new version on order and will feel a lot less worried with a spare. tim -- tim Rowledge; ***@***.***; http://www.rowledge.org/tim No single raindrop believes it is to blame for the flood