Menu
▾
▴
1 Attachments
#46 retries needed for stm32l432
I was having trouble getting downloads to the stm32l432 devices to work so I added retries in the dfuse_dnload_chunk() and dfuse_special_command() functions with some short delays and have not had any more download issues. dfuse.c source attached.
Discussion
Anonymous
content provided
Is this the same issue as in ticket #40? Can you please try my patches there?
Do not know - First time using dfu-util and the SF bug track interface -
Will try & find out.
[edit: removed quoted mail with exposed mail addresses]
Last edit: Tormod Volden 2017-06-11
Yes. The retries just need to be done in dfuse_dnload_chunk() and
dfuse_special_command(). So far I have not needed more than one retry at a
time but having more in the error path does not affect the success path.
Thanks for the tool. This is a lot nicer than using st-link to get
binaries onto these ST devices.
[edit: removed quoted mail with exposed mail addresses]
Last edit: Tormod Volden 2017-06-11
What board is used? Maybe this is a problem with virtual comm port used?
ladybug, butterfly, and my own board -- the issue seems to follow the
stm32l4xx parts and from what I found online looking for a solution
also some of the stm32f4xx parts
Last edit: Tormod Volden 2017-06-13
Disregard last remark. Wrong project!
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
This solves #40 for me, unlike the patch in that thread. /nn
When it decides to fail, it is on a call to dfu_get_status(). It will
happen multiple times during a download. But it has not failed two
dfu_get_status() calls back to back.
I should be able to get back to this Thursday night. Band practice tonight
and tomorrow night.
Last edit: Tormod Volden 2018-02-11
nn, so in your case it fails on the first dfu_get_status() ? It is the first dfu_get_status() that is meant to launch the erase/write, so the chip shouldn't be unresponsive already. Would the patches in #40 work if you preset timeout and remove "timeout == 0" and "!firstpoll" in them?
Please post verbose logs.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Here are three logs: .09 for the Arch packages of dfu-util 0.9. .p1 for the patch in the issue 40 thread, .p2 for the updated version in this thread.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
I'm not sure I understand what you're saying about presetting the timeout - where in the code are you referring to?
It is where it has "int timeout = 0;". Normally the response from the first dfu_get_status() is used to set the timeout value (from the bwPollTimeOut field). So to use the timeout variable before a valid response, you can initialize it to a non-zero value instead.
Hello, I have tried this as well as the patches in ticket #40, but this change seems cleaner... Extracted it into the following patch. In my case (STM32L433) i only need one retry and dfu_get_status() always returned -9 (DFU_STATUS_ERROR_NOTDONE), it would also be possible to put the retry into dfu_get_status()...
You anonymous guy(s) please sign with a name (even a made up one) so I can have a clue if it is the same person or another one.
Anonymous with patch, what I really would like to avoid is random sleeps and also a random number of retries. If we get e.g. DFU_STATUS_ERROR_NOTDONE we'd better sleep the time indicated in the bwPollTimeOut field. Does the returned value make sense in this case?