USB DFU: STM32: usb dfu mode doesn't work #15497
Comments
|
More logs are attached here: |
|
By the way, the command
|
|
Also, I tried the suggested solutions to the issue #14882, no luck to make it work on the nucleo_f429zi board. |
|
I have seen similar behavior on the nrf52840_pca10056, but attributed it to the fact that I was on a VM. I know @jfischer-phytec-iot can reproduce the issue so hopefully he will be able to help out |
|
@jli157 Ubuntu 16.04 native or inside a VM? |
|
@jli157 Can you test it with http://github.com/zephyrproject-rtos/zephyr/pull/9412 (if yes then please rebase it on latest master) ? |
My Ubuntu is running in a Parallel virtual machine but the USB devices are given to the virtual machine during my development. I guess the timeout parameters for USB on a VM could be a bit different from native ones. However, should we also support development on a VM? You can also tell me what kind of parameters I should adjust to make it work if you suspect VM is the culprit? I'd like to try it. :) By the way, what problem did you find from the logs I captured? |
Sure, I'll give it a try. |
|
@jfischer-phytec-iot Good news! The DFU works on my native Linux computer. However, it still doesn't work on VM even with the new stm32 usb patch you mentioned. Is there a solution to make it work for Linux on VM as well? I'm highly relying on my VM for my daily work. Also, the download speed is very very slow even though I disabled all debugging logs. |
|
Host logs for downloading. The downloading took almost 1 hour! |
@jfischer-phytec-iot After reverting ea177e7, the download speed is hundred times faster than the current one from the master branch. :) I think the patch needs to carefully be improved again. |
|
@jfischer-phytec-iot Any suggestions to solve the slow flashing issue introduced by ea177e7? |
|
@jli157 as alternative workaround you can set USB_DFU_DNLOAD_POLLTIMEOUT to 256 I consider to revert ea177e7, at present there is no solution to be sure that a control stage had success before start erase process. |
Reverting ea177e7 already works for me. I'm just thinking what's the next you like to do for a better solution. Do you recommend to close this issue or rename it to something like slowing DFU issue? |
|
Please let it open, I have an idea how to fix but tend to revert it for now. |
Partially revert commit ea177e7 ("usb: dfu: set bwPollTimeout dynamically") Introduced fix does not work proper because there is no way to be sure that a control stage had success before start erase process. Instead IMG_ERASE_PROGRESSIVELY configuration should be used if the erase of the flash takes longer time. resolves: zephyrproject-rtos#15497 Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Partially revert commit ea177e7 ("usb: dfu: set bwPollTimeout dynamically") Introduced fix does not work proper because there is no way to be sure that a control stage had success before start erase process. Instead IMG_ERASE_PROGRESSIVELY configuration should be used if the erase of the flash takes longer time. resolves: #15497 Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Partially revert commit ea177e7 ("usb: dfu: set bwPollTimeout dynamically") Introduced fix does not work proper because there is no way to be sure that a control stage had success before start erase process. Instead IMG_ERASE_PROGRESSIVELY configuration should be used if the erase of the flash takes longer time. resolves: #15497 Signed-off-by: Johann Fischer <j.fischer@phytec.de>
|
@carlescufi and @jfischer-phytec-iot can you reopen this issue? I verified that the issue happened again on the latest master ( fc3270d). Even the command My test is on a real Ubuntu 16.04 Linux instead of a VM. Thank you! |
|
I also noticed several issues on the current master, not only with dfu class. Please also note that some parts of the usb code has been changed. Can you please test |
|
@jli157 can you please retest this with the latest master? |
|
@carlescufi @jfischer-phytec-iot checked again on the same board. It works well now: I can list out two partitions and download an image file to the board. Thank you! |
Partially revert commit ea177e7 ("usb: dfu: set bwPollTimeout dynamically") Introduced fix does not work proper because there is no way to be sure that a control stage had success before start erase process. Instead IMG_ERASE_PROGRESSIVELY configuration should be used if the erase of the flash takes longer time. resolves: #15497 Signed-off-by: Johann Fischer <j.fischer@phytec.de>
I also has issues with time out, apparently I found the all massive debug log cause the time problems. Now it work also in virtual linux machine also. |
|
I also has issues with time out, apparently I found the all massive debug log cause the time out problems. Now it work also in virtual Linux machine also. |
Describe the bug
Tried the sample
samples/subsys/usb/dfuwithmcubooton a Nucleo_F429ZI board, strictly following the instructions by the README. However, the DFU function never works: dfu-util can't do any operations like upload, download or query. The master branch is as of 04/16/2019 (the head is db8d328).To Reproduce
Steps to reproduce the behavior:
west build -b nucleo_f429zidfu's readme.west flash --hex-file zephyr.signed.hexExpected behavior
The dfu-util commands listed in the
READMEshould work. However, no one works. The outputs from the commands and device logs are attached.Impact
prevent my project from enabling the DFU function.
Environment (please complete the following information):
Screenshots or console output
The text was updated successfully, but these errors were encountered: