The initial several tries all stopped at or around 16%. After an unplug and boot+reset (necessary since the first failure) and setting the upload to be verbose in Arduino settings, it now stops at or about 4%.
@NoSloppy I’m not using a hub (it is a front panel connector), but I will try another port. Arduino IDE is version 1.8.3, which is the one recommended here: ProffieOS I’ll try a later version after I look around for another cable that will fit.
Tried another cable, and a back port. Same error, but a larger variety of upload progress. But not consistently with cable or port. One made it all the way to 58%. Also had some which fail with same error at 0%.
Larger paste of the whole console output (with some redacted paths). Nothing that stands out to me as important, but I’m not particularly familiar with dfu stuff.
/home/<user-dir>/.arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld:/home/<user-dir>/.arduino15/packages/proffieboard/hardware/stm32l4/3.6.0/variants/STM32L433CC-ProffieboardV2/linker_scripts/STM32L433CC_FLASH.ld:224: warning: memory region `SRAM2' not declared
/home/<user-dir>/.arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 8 bytes
/home/<user-dir>/.arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 8 bytes
/home/<user-dir>/.arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 8 bytes
/home/<user-dir>/.arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 8 bytes
/home/<user-dir>/.arduino15/packages/proffieboard/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 8 bytes
Sketch uses 175504 bytes (66%) of program storage space. Maximum is 262144 bytes.
/home/<user-dir>/.arduino15/packages/proffieboard/hardware/stm32l4/3.6.0/tools/linux/stm32l4-upload 0x1209 0x6668 /tmp/arduino_build_236399/ProffieOS.ino.dfu
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuDNLOAD-IDLE, status = 0
aborting previous incomplete transfer
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 175512
Download [= ] 4% 8192 bytesdfu-util: Error during download get_status
OK
This is good news though.
if it always stops at the same point, then the problem is the flash memory.
If it stops randomly at different spots, then the problem is something else. The most common cause is a bad usb cable, but sometimes it’s something else, like a short somewhere, or a bad 3.3v regulator. Other things to check for would be a loose usb connector on the board, stuff touching the board that shouldn’t be, or cracked solder joints.
Four more USB micro cables, same issue with all of them.
The board is mounted (new pre-installed Darkwolf LGT core), and my eyes aren’t as good as they once were (nor do I have magnifier tools right now), but I don’t see any visible issues on the board where it’s exposed. The USB connector seems to be solid.
The variable nature of the value does make it sound like what you suggest. I don’t have an oscilloscope to properly monitor the vreg right now, but I can try to do limited testing with my multimeter.
I’ll have to pick this back up hopefully tomorrow though, too late to continue tonight.
Is your battery plugged in while you’re doing this?
If not, try it with the battery. If that works better, then maybe the problem is D62, which connects usb power to the 3.3V regulator.
I have been attempting to upload with the battery in only. I had tried at one point to do an upload without the battery, but the reset+boot buttons are difficult to access, so I must have failed to get them pressed properly. I did get it to connect without the battery, but same error during upload.
Nothing on the board that I can access gets hot or even warm, really. However, the components towards the sides of the bottom are covered where I can’t measure/touch.
Yes, 3.3v pin measure ~3.3v. I only have a multimeter, so I can’t really check the stability beyond just having it there for a bit and watching the screen, but it was stable for at least several seconds.
I actually had a successful upload! Just one though. I had the battery out of it, and I was holding it (high risk of jostle). (Also, woohoo! My initial test config worked exactly as expected!)
With a working upload*, I’ve had the serial monitor with monitor battery running for a while, and no sign of disconnect or corruption, even while jostling the usb connector.
*I attempted another upload (of the same code), which failed at 2%, but the board continued to work, so I decided to see if I could use the functional state to test other possibilities.
I was expecting the issue to be bad usb connection, which I guess is still possible, but seems less likely now?
What, if anything, can I use this currently working upload to try?
It’s more than a little strange that the serial monitor is stable, but uploads are not.
Those two things use almost entirely the same components and circuits.
Maybe the problem isn’t on the board, but on the computer?
Some sort of software that is trying to talk to DFU devices maybe?
I don’t suppose you could try a different computer?
I attempted to get my laptop (also Xubuntu) setup to upload with, but it gets the countdown timers and then failure there consistently, not even making it to the same state. And that was after having to install some other system stuff to make compiling work in the first place. The USB DFU device is recognized, so there’s something else going on there.
I have found some mentions of similar issues, and with the same chips, and some cases seem to be related to finicky bootloader firmware. For several different people the solution was to upgrade dfu-util, and those were in 2020 to the master tree. As far as I can tell, those changes are merged into at least the latest 0.11 release, so I pulled down those binaries and swapped them into the driver folder. Same result, though there’s a successful erase process output to the console that happens first.
I haven’t figure out a way to detect other software interfering with the upload, but it also seems likely that it’s a repeat of these bootloader issues I’ve found. The issue could still end up being specific-ish to this computer.
I was trying to avoid actually building dfu-util myself, but checking out the previous fix and seeing if there’s an obvious more aggressive version of the tweaks might be one of the next steps.
Hmm, I didn’t realize this was on linux before.
The page you linked is interesting though. It suggests that the bootloader can time out the USB bus while erasing pages. I’m not sure why that’s never been a problem for me though, I’ve been programming these things on linux for years. Although, I almost always use a hub, maybe that’s why?
Finally found something that worked! The patches from ticket #40 over there didn’t work, but from dfu-util / Tickets / #46 retries needed for stm32l432 I applied these changes to current master branch of dfu-util (commit hash 513468):
diff --git a/src/dfuse.c b/src/dfuse.c
index 17a62f6..301a42f 100644
--- a/src/dfuse.c
+++ b/src/dfuse.c
@@ -291,6 +291,7 @@ static int dfuse_dnload_chunk(struct dfu_if *dif, unsigned char *data, int size,
int bytes_sent;
struct dfu_status dst;
int ret;
+ int retries = 0;
ret = dfuse_download(dif, size, size ? data : NULL, transaction);
if (ret < 0) {
@@ -300,8 +301,14 @@ static int dfuse_dnload_chunk(struct dfu_if *dif, unsigned char *data, int size,
bytes_sent = ret;
do {
+retry:
ret = dfu_get_status(dif, &dst);
if (ret < 0) {
+ if (++retries < 10) {
+ usleep(10);
+ goto retry;
+ }
+
errx(EX_IOERR, "Error during download get_status");
return ret;
}
I’m just trying to pretend it doesn’t use goto and being happy that something works.
I am also ashamed that I missed specifying my OS in the first post. I think I assumed that I had in my responses after.