Activity for Tormod Volden
-
Tormod Volden posted a comment on ticket #173
Sure. (Sorry, I didn't see the Anonymous post before now.) Binary for 64-bit Windows, not tested.
-
linting etc fixes merge request
-
If you look at the latest git version you can see that I already put in placeholders for these chips, with some values filled in. It even has a complete and active (but not verified) entry for the 585xx chips. Some values differ from yours. So we should try to find out which values are best.
-
Thank so much! Can you please also tell where you have the information from (datasheet revision, other document references) so that it can be double-checked? The option bytes and sectors can be tricky for some systems but it helps to know what your assumptions are based on.
-
If you are asking about the same issue in different forums, it is useful (and polite) to mention this and provide links. https://github.com/libusb/libusb/issues/1717
-
Xilinx (AMD) bootloader (FSBL) issues on Windows
-
It is not often that ELF files are used to provide firmware to end users as in this example. However it is often the primary build artifact so it would be convenient for development. It is interesting that StmDfuUsb supports ELF files because it is not mentioned on the home page https://yatrim.com/stmdfuusb I am not hugely in favour of adding all kind of file formats to dfu-util, because it adds complexity, maintenance burden and probably build dependencies. I would prefer it being added to the dfuse-pack.py...
-
You mention StmDfuUsb but not anything about what device and bootloader it is. Please see https://sourceforge.net/p/dfu-util/tickets/new/ You can convert the ELF file to a binary using objcopy. If it is a standard DFU 1.1 device then that's all fine, but if it a DfuSe bootloader you must know where to load it, this information is in the ELF file but not in the binary file.
-
I remember having seen, many years ago, an issue with a program running via Python's subprocess. I will try to recall or find back to it. You said that you added a lock that assures only one invocation of dfu-util is running at a time, but that didn't help. It therefore seems to me that the problem is not running dfu-util in parallel, but something else.
-
Thanks for your feedback. Yes, I have also been thinking about this and for long :) It is good to receive some feedback on the latest git, and that these changes have an impact. I usually don't hear anything on this side unless something is broken... I will look at retargeting those milestones and make a release soon.
-
Arduino exit status 74 Failed uploading: uploading error: exit status 1
-
To clarify, this is a bug in the Arduino IDE (or its esp32 board package). You must report it there. Here on the dfu-util side there is nothing we can do. The Arduino people are bundling dfu-util with their setup, but we cannot fix their setup.
-
Thanks, I have now learned to generate directory index files with "tree" :) But why did this happen all of a sudden without notice? Where can I follow news about the project hosting service?
-
Cannot open DFU device 2341:0366 found on devnum 34 (LIBUSB_ERROR_NOT_FOUND) This means the device shortly showed up, but then disappeared before dfu-util could connect.
-
Ah OK. Where is this documented or advertised? I missed out on it.
-
I brought this up in #26781 instead since I cannot reopen this ticket.
-
Server-generated directory indexes
-
For now I hand-crafted some index.html pages with links to the files, but the server-made indexes would be nice to have back.
-
It all worked fine last night, but now I get "403 Forbidden" "nginx" on the sub folders. They have an .htaccess with "Options +Indexes". File permissions seems fine AFAICS.
-
Thanks a lot for your answer, and or for restoring the web pages already! No problem, the website is all static.
-
please restore deleted kst/htdocs folder
-
Regression: required delay before entering boot loader mode
-
I would test it with the following line, if someone provide a binary to me: /* {0x489, "STM32U073xx/83xx" , 0x20002170, 0x2000A000, 0x08000000, 0x08040000, 1, p_2k, 0x1FFF7800, 0x1FFF7860, 0x1FFF0000, 0x1FFF6800, 0}, */ Here the reference documents AN2606 rev 66 SRAM Table 209 STM32U073xx/83xx System-mem-addr Table 192 26 Kbytes, starting from address 1FFF0000, STM32U0 – FLASH Memory Flash presentation Flash-Address: Main Memory Page 7 PSize: Page 7 Option Byte: Page Option Bytes are used to early...
-
Thanks! Here is binary with your patch.
-
Thanks! Here is binary with your patch. (The attachment ended up in the original post.)
-
Thanks! Here is binary with your patch. (The attachment ended up in the original post.)
-
STM32U0 Support - Unknown/unsupported device (Device ID: 0x489)
-
Thanks! Here is binary with you patch.
-
It is possible that it just needs the right parameters in dev_table.c and it will work. I have added placeholders for this device (and all other devices in latest AN2606) in dev_table.c, in hope that people will contribute the missing pieces, after looking up the individual data sheets and testing on their devices.
-
No DFU capable USB device available
-
No DFU capable USB device available Without more information there is not much we can do about it.
-
dfu-util 0.9 is pretty old. You should try to update your Arduino board package for your board/device. I don't think the dfu-util version is the real problem, but newer versions are more helpful for debugging. In any case, here it looks like the firmware file could not be found, so there is nothing dfu-util can do about it.
-
dfu-util doesn't access serial ports (nor virtual serial ports). LIBUSB_ERROR_ACCESS indicates a permission issue or driver conflict. Please see https://sourceforge.net/p/dfu-util/tickets/186/
-
Did you look inside the file?
-
You can use dfu-suffix to change or remove the VID:PID of the firmware file.
-
Please see https://sourceforge.net/p/dfu-util/tickets/186/
-
BTW, why are you using -t 0 ?
-
Warning: Invalid DFU suffix signature
-
Arduino ESP32 "No DFU capable USB device available"
-
Arduino Nano ESP32 "LIBUSB_ERROR_NOT_FOUND"
-
Arduino UNO R4 minima LIBUSB_ERROR_NOT_FOUND
-
Sri, I mistakenly thought it was you posting as anonymous above. Your original problem is the same as in https://sourceforge.net/p/dfu-util/tickets/207/ so I will close this ticket. You can reopen it if you have more information. The anonymous posters can post in https://sourceforge.net/p/dfu-util/tickets/197
-
candleLight flash can bus
-
You'll need to provide more information, see https://sourceforge.net/p/dfu-util/tickets/new/
-
Arduino UNO R4 minima LIBUSB_ERROR_NOT_FOUND
-
Failed uploading: uploading error: exit status 74 (bad cable)
-
hackrf dfu crc mismatch
-
You'll have to post all information and logs, as instructed on https://sourceforge.net/p/dfu-util/tickets/new/ otherwise I have to second-guess what is going on.
-
Now since you are on (Fedora) Linux, you should be able to follow what is happening, using journalctl -f or tail -f /var/log/syslog . You will probably see the USB device 2341:0069 appear, but then disconnect. This is also interesting: Claiming USB DFU (Run-Time) Interface... This means the device is in Run-Time mode and not in bootloader (that would be DFU mode). I don't know anything about these devices so I don't know if this is intended. Is another device showing up after the "DFU detach request"...
-
Now since you are on (Fedora) Linux, you should be able to follow what is happening, using journalctl -f or tail -f /var/log/syslog . You will probably see the USB device 2341:0069 appear, but then disconnect. This is also interesting: Claiming USB DFU (Run-Time) Interface... This means the device is in Run-Time mode and not in bootloader (that would be DFU mode). I don't know anything about these devices so I don't know if this is intended.
-
dfu-util: Lost device after RESET? The device disappears, so dfu-util cannot do anything. This must be fixed in the Arduino IDE or bootloader. dfu-util 0.11-arduino4 This is Arduino's own version of dfu-util. There seems to be a newer dfu-util 0.11-arduino5 out, you should try that also.
-
Please see for instance https://sourceforge.net/p/dfu-util/tickets/186/ There is nothing that dfu-util can do about the situation, the problem is in the Arduino IDE.
-
esp32 No DFU capable USB device available
-
Please see ST's AN2606 document for the details of your chip. And generally, make sure all other UART or SPI lines are quiet.
-
Is there something I need to configure on the STM32 side to properly support the stm32flash utility? So far I've not gotten into the STM32 side of things, as another engineer is working on that SW.
-
It doesn't matter if I use "echo 1 | tee" or "echo 1". I put my multimeter on BOOT0 & MCU_RSTn pins and added an exit from one stage to another. Both pins are set correctly throughout the script.
-
Please don't post images of text, just copy and paste the text. Can't you just flash the part at 0x08000000 with one stm32flash invocation and the part at 0x08100000 with another?
-
Flashing STM32F446 fails at 30%
-
Are you sure echo 1 > file isn't interpreted as echo with stdout (file handle 1) redirected? I usually use echo 1 | tee file which avoids any ambiguity (and also because I can use sudo tee easily).
-
Just one tip: If you want to set up the serial port using stty and keep stm32flash from reconfiguring the port, use -b 0.
-
Is there any indication there is something wrong in dfu-util still?
-
It is there in your 0.9 output as well: Determining device status: state = dfuERROR, status = 10 v0.11 is more helpful with telling what "10" means.
-
This is the status that the bootloader itself reports. I think it is just a bug in the ST bootloader. It would make sense if this status would be reported before anything is programmed (and there would be no run-time to go to), but I don't know if and how the bootloader tries to determine this. Maybe it is meant to check if there is a valid stack and boot vector at 0x08000000, but I don't know what your device bootloader is actually doing. The dmesg output on the host may reveal if the device is...
-
So it seems erase and programming works fine without issues. Are you sure it /remains/ in bootloader after the leave request, and that it doesn't reset and, for some reason or another (BOOTx pins?) boots into the bootloader again?
-
Please try 0.11 or latest git, and paste the output. If on latest git, you can also try the ":fast" modifier.
-
Thanks for a good and detailed bug report. Unfortunately, the LIBUSB_ERROR_NOT_FOUND appearing together with "found on devnum XX" means that the DFU device was available for a short time but then disappeared. It is probably not staying long enough in DFU mode. This is a problem in the device bootloader, or the program (IDE) that puts it into DFU mode. There is not much dfu-util can do about it.
-
Or .hex file.
-
It seems that you are programming an .elf file directly onto the device. You should extract a binary file from the ELF file and use that instead.
-
https://github.com/mchehab/zbar/issues/212
-
Interesting, thanks! At a first view, this seems to make sense. It is limited to 65535-2 blocks though, but that can be dealt with if necessary. How much is the gain that you are seeing?
-
The warning that you put in the title is just a warning. It has nothing to do with "No DFU capable USB device available". Did you at all read https://sourceforge.net/p/dfu-util/tickets/new/ ?
-
Thank you Here at the dfu-util bug tracker we only deal with dfu-util itself, not the Arduino IDE. Arduino bundles their own modified version of dfu-util. This is the the problem that dfu-util sees (exit status 74 is just a code for this): |dfu-util: No DFU capable USB device available| So the Arduino IDE hasn't successfully made a DFU device available for dfu-util.
-
symbol lookup error after new install
-
So the /usr/local/lib/libusb-1.0.so.0 that you deleted showed up again after reboot? No, I have never run into this before. Maybe you have a boot script installing it, or a file syncing service that reinstates it.
-
Thanks so much, this solved the problem and I am now able to send the rootfs.ext4 file, but u-boot is rejecting it now (not dfu-util issue at this point). I think we can safely close this ticket.
-
It is happening again and I have not touched a thing. I rebooted my laptop, and tried to use dfu-util again. sudo dfu-util -l dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option ldd output: sudo ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffed54f7000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073306e600000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073306e200000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073306e9b2000) libpthread.so.0...
-
(LIBUSB_ERROR_ACCESS)
-
You should create a udev rules file for your device, see e.g. https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/doc/60-dfuse.rules
-
Arduino: No DFU capable USB device available
-
Here at the dfu-util bug tracker we only deal with dfu-util itself, not the Arduino IDE. Arduino bundles their own modified version of dfu-util. This is the the problem that dfu-util sees (exit status 74 is just a code for this): dfu-util: No DFU capable USB device available So the Arduino IDE hasn't successfully made a DFU device available for dfu-util.
-
Anonymous, can you share more details of your USB captures? And does version 0.9 work for you, like for the original poster?
-
I followed the build manual on the dfu-util site. I already had libusb-1.0.0-dev installed. I did install dfu-util executable into /usr/local/bin. After running ldd: ldd /usr/local/bin/dfu-util linux-vdso.so.1 (0x00007ffee19ad000) libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073d5ad600000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073d5adcb8000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000073d5adcb3000)...
-
Exactly, your dfu-util binary is run-time linking a libusb in /usr/local/bin: libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000) This is not the libusb that comes with the distro as part of libusb-1.0-0-dev, and which is referenced during building. Hence the mismatch when running dfu-util. Simply delete the (apparently very) old libusb that you have in /usr/local/lib.
-
Running dfu-util -l command multiple times, changing the device info.
-
It looks like a hardware issue on your device. You'd have to provide more information and debug logs, see what is demanded on https://sourceforge.net/p/dfu-util/tickets/new/
-
It could be that you are building against one version of libusb and then run-time linking against another version. To start with, make sure you are running the correct dfu-util binary: type dfu-util You said you built dfu-util 0.11 but did you install it, and where? /usr/local/bin ? Then run ldd on that file, e.g. ldd /usr/local/bin/dfu-util This will list which libusb .so file will be run-time linked. Typical candidates for confusion would be a custom-installed libusb in /usr/local/lib in addition...
-
Cannot open DFU device
-
Please see the text on https://sourceforge.net/p/dfu-util/tickets/new/ (and Anonymous posters trying to hi-jack this report please see https://sourceforge.net/p/dfu-util/tickets/197/ )
-
fatal error occured: COM9
-
Please see the text on https://sourceforge.net/p/dfu-util/tickets/new/ (and Anonymous posters trying to hi-jack this report please see https://sourceforge.net/p/dfu-util/tickets/197/ )
-
As explained in the description: Note if dfu-util reports "No DFU capable USB device available" there is a 99% chance the error lies in your "microcontroller development" GUI / Arduino IDE or the device bootloader setup, and there is nothing dfu-util can do about it. In this case please consider reporting the bug in the appropriate channels and forums and not here.
-
* Anonymous please post here *
-
Failed to init device using "-i '-dtr&rts,dtr:-dtr&-rts,dtr'" param
-
No, I don't think you understand this at all :) These are serial port control lines, for instance on a USB-serial adapter you may find DTR and RTS in addition to the mandatory TX and RX lines. In this context they can be used like GPIOs on the host. For controlling the STM32 boot mode from the host, these lines (or GPIOs) can be hooked up to Reset and BOOT0 on the STM32. If you are setting BOOT0 (and BOOT1) manually, and also reset the STM32 manually, you don't need to think about any "init sequence"....
-
What are DTR and RTS connected to?
1 >