Is There a Kiss of Life for this Dead Proffie 2.2?

Sabersense · April 30, 2024, 2:00pm

I’m trying to revive a seemingly dead board. It seems Arduino can occasionally see it, but uploads always fail.
Tried all the usual stuff (Boot/Reset etc., holding boot while plugging in USB…), but no joy.
Just thought I’d share these error logs in case they mean anything to anyone before I get the soldering iron out to replace it. The logs are mostly the same, but they do vary a little.

/Users/chrisandlindsey/Library/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:/Users/chrisandlindsey/Library/Arduino15/packages/proffieboard/hardware/stm32l4/3.6.0/variants/STM32L433CC-ProffieboardV2/linker_scripts/STM32L433CC_FLASH.ld:224: warning: memory region `SRAM2' not declared
Sketch uses 233184 bytes (88%) of program storage space. Maximum is 262144 bytes.
10
9
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 = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 233192
Download	[                         ]   0%            0 bytesdfu-util: dfuse_download: libusb_control_transfer returned -1
OK

/Users/chrisandlindsey/Library/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:/Users/chrisandlindsey/Library/Arduino15/packages/proffieboard/hardware/stm32l4/3.6.0/variants/STM32L433CC-ProffieboardV2/linker_scripts/STM32L433CC_FLASH.ld:224: warning: memory region `SRAM2' not declared
Sketch uses 233184 bytes (88%) of program storage space. Maximum is 262144 bytes.
10
9
8
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 ...
dfu-util: Error during special command "ERASE_PAGE" get_status
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 233192
Download	[                         ]   0%            0 bytesOK

/Users/chrisandlindsey/Library/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:/Users/chrisandlindsey/Library/Arduino15/packages/proffieboard/hardware/stm32l4/3.6.0/variants/STM32L433CC-ProffieboardV2/linker_scripts/STM32L433CC_FLASH.ld:224: warning: memory region `SRAM2' not declared
Sketch uses 233184 bytes (88%) of program storage space. Maximum is 262144 bytes.
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 ...
dfu-util: Could not read name, sscanf returned 0
dfu-util: Failed to parse memory layout
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
OK

/Users/chrisandlindsey/Library/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:/Users/chrisandlindsey/Library/Arduino15/packages/proffieboard/hardware/stm32l4/3.6.0/variants/STM32L433CC-ProffieboardV2/linker_scripts/STM32L433CC_FLASH.ld:224: warning: memory region `SRAM2' not declared
Sketch uses 233184 bytes (88%) of program storage space. Maximum is 262144 bytes.
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 ...
dfu-util: error get_status
Determining device status: OK

NoSloppy · April 30, 2024, 3:29pm

Did you try with battery and without?
Did you try a different cable?
A different USB hole on the computer?
Do you have 3.3v on SD Power Pad?

profezzorn · April 30, 2024, 7:30pm

This sort of thing tends to happen because something isn’t stable. It could be the power, the USB cable or something going on on your computer.

Trying it with a battery connected could be helpful.
Trying a different USB cable could be helpful.
Trying a different computer could be helpful.

If none of these work, de-solder everything from the board and try again.
If it now works, then the problem was somehow in the wiring (a short somewhere maybe?)

If it still doesn’t work, but other boards do, then the problem must be the board itself.

Sabersense · April 30, 2024, 8:29pm

Respectively:
Yep,
Yep,
No,
Well, yes I do now!

Bizarrely, after much trying essentially the same thing, it suddenly worked and is now functioning correctly. However I’m not convinced that all is as it should be. Earlier on today, I had one upload that came agonisngly close to working, but then failed at the final hurdle. The Arduino error looked like this:

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 = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 233192
Download [======================= ] 94% 221184 bytesdfu-util: dfuse_download: libusb_control_transfer returned -1
OK

I’ve never seen an upload give up at 94 percent like that. But later on it suddenly worked properly and I’ve tried several uploads since, all of which have been OK.

So I’ve no idea what was/is going on. All I can do is keep soak testing and see where it goes.

Curiouser and curiouser.
The case continues…

jedi_j_stream · April 30, 2024, 8:36pm

I’ve had issues with a few LGT chassis with a proffie v2.2. Repeated sequences of Boot+Reset while connected via USB would eventually get me into STM bootloader mode. I was then able to reflash the board even though it was not recognized by Arduino, although it sometimes took multiple attempts to flash before it worked successfully–and sometimes multiple resets after flashing successfully to get it out of boot-loader mode. In at least one case I also swapped the SD card but I’m not sure if that was causal, contributing, or coincidental to getting that one to work again… they are all working now, but I’ve put them back on the shelf and play with the hilts that have more durable electronics.

profezzorn · April 30, 2024, 8:42pm

It’s usually due to a poor USB connection.
Either power or data gives out in the middle.
It’s worse if it happens at the same place each time, because that means that the flash memory in the chip itself is broken…

Sabersense · May 6, 2024, 6:18am

Update to this:
As mentioned above, I managed to somehow upload a new config (by a complete fluke - one of the many attempts just suddenly ‘took’), and after that I could upload other configs pretty reliably. But last night I tried running sdtest through serial monitor, and it just stalled halfway through. Now I’m struggling to see the board in Arduino. Bizarrely it shows under ports sometimes, but even when it does, I still get the 10 countdown when I try to upload.

From a saber user perspective though, it seems to be working, as long as they never want to change the config. (Which is obviously no good).

I’ve tried reflowing all the solder joints that connect the USB socket to the board, and also ‘tweaked’ the USB socket slightly so it holds the cable connector more tightly. Tried different cables, different USB ports, rebooted computer, but nothing seems to make much difference.

Now out of ammo, so it looks like I need to concede defeat and replace it.

Thanks for the thoughts above though - much appreciated.

profezzorn · May 9, 2024, 4:27am

Does the serial monitor work?
It’s possible that your computer just wants more than 10 seconds to identify the USB device. If that is the case, you can change the script to count to 30 instead of 10. Or, you could use the RebootDFU command in the serial monitor to make it boot into DFU mode before doing the upload.