DFU Flashing error for the new DFU files on Windows

[Johnex]

Describe the bug
"More than one DFU capable USB device found!" Error when flashing Pinecil 2.16 dfu file on Windows.

To Reproduce
Following the Flashing Guide for Pinecil I ran the following command:
dfu-util -D Pinecil_multi_compressed_European.dfu

The output is the following:
More than one DFU capable USB device found! Try --list and specify the serial number or disconnect all but one device

Running the --list command gives:

Found DFU: [28e9:0189] ver=0100, devnum=9, cfg=1, intf=0, path="1-1", alt=1, name="@Option Bytes  /0x1FFFF800/01*016Be", serial="3TBJ"
Found DFU: [28e9:0189] ver=0100, devnum=9, cfg=1, intf=0, path="1-1", alt=0, name="@Internal Flash  /0x08000000/128*001Kg", serial="3TBJ"

Flashing with more flags to set the partition succeeds:
dfu-util -a 0 -D Pinecil_multi_compressed_European.dfu -s 0x08000000

But the device does not boot at all. The screen is black and usb reports a bad usb device. Reverting back to 2.15 works fine.

Expected behavior
Flashing to succeed without the error

Details on your device:

• Device: Pinecil
• Release: 2.15

[Ralim]

Hi,

This feels like you have an old dfu-util version installed.

For example this is flashing the file for me:

sudo dfu-util -D Pinecil_multi_compressed_European.dfu 
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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/

Match vendor ID from file: 28e9
Match product ID from file: 0189
Multiple alternate interfaces for DfuSe file
Opening DFU capable USB device...
Device ID 28e9:0189
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #1 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Option Bytes  "
dfu-util: Non-valid multiplier ' ', assuming bytes
DfuSe interface name: "Internal Flash  "
Found GD32VF103, which reports a bad page size and count for its internal memory.
Fixed layout based on part number: page size 1024, count 128.
File contains 1 DFU images
Parsing DFU image 1
Target name: ST...
Image for alternate setting 0, (1 elements, total size = 94620)
Setting Alternate Interface #0 ...
Parsing element 1, address = 0x08000000, size = 94612
Erase           [=========================] 100%        94612 bytes
Erase    done.
Download        [=========================] 100%        94612 bytes
Download done.
Done parsing DfuSe file

If I try and use the -s parameter on the file it throws an error as this file has the header that alrady specifies this:

dfu-util -D Pinecil_multi_compressed_European.dfu -s 0x08000000
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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/

Match vendor ID from file: 28e9
Match product ID from file: 0189
Multiple alternate interfaces for DfuSe file
Opening DFU capable USB device...
Device ID 28e9:0189
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #1 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Option Bytes  "
dfu-util: Non-valid multiplier ' ', assuming bytes
DfuSe interface name: "Internal Flash  "
Found GD32VF103, which reports a bad page size and count for its internal memory.
Fixed layout based on part number: page size 1024, count 128.
dfu-util: This is a DfuSe file, not meant for raw download

So I'm suspect the version of dfu-util you are using is too old for this and is flashing the dfu header to the device instead. (And thus it wont boot as its not riscv code)

[Johnex]

You might be right. I used the dfu-util included with the Pinecil Updater tool from here:
https://github.com/pine64/pinecil-firmware-updater/releases/tag/1.3

So you might want to warn those guys as well. About the new DFU changes and the binary they include not being compatible 👍

NVM, ill write them :D

[publicarray]

@Johnex I think I got ahead of you: pine64/pine64_updater#17

[Johnex]

Almost 😂

[Ralim]

Ah that would make sense as a reason for the issue.
I think best thing here is to wait for that software to update or download a newer dfu-util release :)

[Johnex]

I downloaded the 0.11 dfu-util from http://dfu-util.sourceforge.net/releases/ flashed 2.16 using:
dfu-util -D Pinecil_multi_compressed_European.bin

And it flashes successfully, but now I have a garbled screen instead of the blank screen?

[Johnex]

Strange. If I let it stay corrupted like that for a few seconds, 10 or so, it fixes itself. Then after I toggle power I get this beauty:

[Ralim]

Now that is odd
To confirm did you flash the .dfu or the .bin file?
I flashed the 2.16-rc here and cant reproduce this issue :/
Could you try dumping flash back out via dfu?

[Johnex]

I flashed the dfu file yeah. Do you have the command for dumping? I tried just dfu-util -d 28e9:0189 -U dump.bin and it warns about multiple devices again 😅

Found DFU: [28e9:0189] ver=0100, devnum=31, cfg=1, intf=0, path="1-1", alt=1, name="@Option Bytes  /0x1FFFF800/01*016Be", serial="3TBJ"
Found DFU: [28e9:0189] ver=0100, devnum=31, cfg=1, intf=0, path="1-1", alt=0, name="@Internal Flash  /0x08000000/128*001Kg", serial="3TBJ"

[Johnex]

Just to note, I flashed back to 2.15 just to test and it works fine, so no permanent damage at least 😋

I flashed 2.16 again and it's the same corrupted :(

Might be unrelated or related, the automatic screen orientation option in the semi corrupt 2.16 does not work.

I thought it might be related to the QC changes, but i tested both using just USB legacy power and USB-C PD, same issue. Could it still be that though? There is a consistent timeout from poweron -> corrupted screen -> fixes itself, about 70 seconds.

[Ralim]

You will need to specify the alt to be 0 by adding -a 0 to the command i believe

The corruption looks like I2C is having a bad day but how you get to that state I'm really not sure.

On the 2.16, does PD work? Does the accerometer work? (You can check this by going into debug menu down to the PCB/ACC option)

[Sat1l]

I'm having the same issue on Mac OS (11.6), though -a 0 fixes everything
And yeah, on my unit on 2.16 accelerometer freaks out and shows that it's not detected. Also PD doesn't work, 96W MacBook power supply outputs only 5W

[Ralim]

You should not require the -a 0 if you are using the .dfu file and dfu-util 0.11
Which file are you flashing?
When on 2.15 what model accelerometer does it show you have?

[Sat1l]

Updated dfu-util, works fine now without -a 0
I'm flashing the Pinecil_multi_compressed_Bulgarian+Russian+Serbian+Ukrainian.dfu
I can't see the accelerometer in debugging menu for some reason, there is just no ACC menu(after Vin it shows PCB), but MOVE menu registers movements successfully

[Ralim]

Ah PCB is the older name sorry,
If MOVE is updating then thats good. Is PD working now ?
You may want to try forcing a settings reset incase the bad flash put crap in the settings area

[Sat1l]

On 2.15 everything works flawlessly
But 2.16 PD is still not working, even after factory reset
Also when I was trying to re install 2.16* dfu-util was freaking out and telling me No DFU capable USB device available. I was connected through usb-c to usb hub with usb to usb-c cable, and the solution was as simple as connecting it with direct usb-c to usb-c cable
And talking about ACC, on 2.16 it shows none and MOVE is not updating

*(got same weird screen with dots as Johnex, after some time it became OK, but after plugging power out and in it just shows "Advanced Options" menu preview and doesn't recover even after some time)

[Ralim]

Hrmm very weird,

No DFU capable USB device available often means you just need to wait (the USB bootloader sometimes takes a few seconds to start up properly and can miss the first round of USB polling).

Can you please try using a non multi-lingual firmware release to narrow down if the issue is related to that or not? (We do some interesting repacking to make them work)

Additionally, have attached a local build with bin and dfu files; if you get time could you please try these as well 🙏🏼

Realise its effort and I apologies, I have not been able to replicate this with local builds or with github builds and would love to narrow down if its firmware or dfu-util related :)
v2.16.zip

[tormodvolden]

Just to clear up a few misunderstandings and misconceptions:

• If you want to upload from the device you have to use --dfuse-address 0x08000000 and you will get a binary file (dfu-util won't create a DfuSe file).
• dfu-util will never write DfuSe headers onto a DfuSe device, because if you use --dfuse-address (which is for binary files) with a DfuSe file it will stop and complain: "This is a DfuSe file, not meant for raw download"
• 0.11 vs 0.10 just makes the -a 0 argument optional (it will use those found in the DfuSe file automatically)

[HanaO00]

I had the same problem with dfu-util 0.11, then the problem disappears and it no longer did it, on the other hand at each start it hangs for 2/3 seconds like a mini-freeze, and on a PD power supply it is as if it confused PD and QC, because it does not exceed the value set in the QC parameters

I am using a pinepower USB-C PD 20V

I downloaded the 0.11 dfu-util from http://dfu-util.sourceforge.net/releases/ flashed 2.16 using:
dfu-util -D Pinecil_multi_compressed_European.bin

And it flashes successfully, but now I have a garbled screen instead of the blank screen?

[Sat1l]

Sorry for waiting, I've remembered that my solder was not made for just playing with firmware xd
Attached release flashes without any issues (.bin), but screen shows the same collection of dots as before, but now its temporary and is not going away whatever you try to do to it

[Ralim]

The mini freeze would indicate that I2C is not working.

You should be able to see the accelerometer model under either ACC or PCB (depending on firmware version).
Would like to know what model you have detected under the old firmware.

Trying to figure out what it is out of :

• I2C driver somehow breaking (has had no code changes)
• Accelerometer code path broken (thus wanting to know model)
• Something breaking from flashing
• Something breaking in the build

[publicarray]

I tried the RC yesterday and had the same issue with the dots on the screen, The old firmware (2.15.40087E6) indicates PCB 5. But I'm going to flash to the RC again with the bin file to see if there are any changes. Edit: no changes. Just dots on a screen and buttons don't appear to do anything (I did not wait long enough to see if it fixes itself).

[Sat1l]

Same here, PCB 5

[Ralim]

Hmm okay PDB 5 is interesting as the SC7A20 is a bit odd.
I have one on a breakout board here somewhere. Give me a bit and ill be back soon-ish with a fix (I hope)

[HanaO00]

I re-flashed the stable release, in the debug menu it is also a PCB 5

[Johnex]

So I reverted back to 2.15 again and noticed the readings were waaaay off. It was reporting USB-C PD voltage as 45V 🤣, so i did a factory reset and that fixed it. If you revert back after testing, make sure to factory reset even if things look normal 👍

I am on PCB 5 as well.

I updated to 2.16 yet again, same issues as before. In the debug menu it says
ACC None
PWR 1 (9V which on 2.15 was the correct 20V)

[HanaO00]

So I reverted back to 2.15 again and noticed the readings were waaaay off. It was reporting USB-C PD voltage as 45V rofl, so i did a factory reset and that fixed it. If you revert back after testing, make sure to factory reset even if things look normal +1

I am on PCB 5 as well.

I updated to 2.16 yet again, same issues as before. In the debug menu it says
ACC None
PWR 1 (9V which on 2.15 was the correct 20V)

I have the same problem with the PD power supply, when you go up to 20V in the QC settings, it goes up to 20V in PD? Strange

[Ralim]

Okay have narrowed this down to a bug somewhere in the I2C state machine setup not playing well with this accelerometer.

Sadly dont have time left tonight to sort this out, but will be on this asap

I have the same problem with the PD power supply, when you go up to 20V in the QC settings, it goes up to 20V in PD? Strange

That would be, because you are using QC not PD

[HanaO00]

I use a pinepower and a lenovo charger, so yes it's PD, but taking the version in the artifacts, to the right of the pinecil screen it shows me the voltage which is set in "QCMaxVoltage", even with PD power supplies I have tested multiple values to be sure and it always shows me the value of this option

[Ralim]

I'm unsure of the Lenovo one, but I can vouch the pinepower does QC to 20V too.

If you adjust the menu without a restart and it updates it has to be QC as the current PD only ever negotiates once per boot cycle.

:/ Otherwise I don't see how it's working like that

[HanaO00]

I was pointing this out thinking it was a problem other users were having as well, it's the portable pinepower with two USB-C (PD) ports and one USB-A (which does QC), I plugged in a 5V fan on it to try and the Pinecil turns on again at 15V it must be normal, otherwise the power supply has a problem, but in all cases the PD values are fixed, from what I think, 15V, 20V ... And by putting 16, 17V in the QC parameters it shows me well 16V, 17V it's really strange

My lenovo PSU is a ADLX65YDC3D

[Ralim]

If you have time (don't feel pressured)
I believe the firmware over at #1099 (Currently the latest is this action is here )

This works on my unit with the SCA, but would love external validation

[Johnex]

I tested the new version, flashed the Pinecil_multi_compressed_European, no issues when flashing and on first boot I got a warning saying some settings had changed. The message was displayed for a long time too, I thought the pinecil had hanged 😅

Accelerometer works fine, PD works fine and everything is work as expected so far 😍👍

When connecting via legacy USB to the computer, I do get a "device not recognized" warning. Would it be possible to fix that in the future so that windows knows at least to only supply power, and not try to mount the device?

[Ralim]

The message was displayed for a long time too

Hmm, how long did it show up for?

When connecting via legacy USB to the computer, I do get a "device not recognized" warning. Would it be possible to fix that in the future so that windows knows at least to only supply power, and not try to mount the device?

Not without disabling support for QuickCharge or adding some method of telling QC chargers apart from a USB host, which I suspect without actually doing USB would be not-fun.

[Johnex]

It showed for like 5 seconds or so? And the boot after that took another few seconds before the main screen showed. After that first boot the main screen shows instantly. I guess it was just related to the settings reset?

[Ralim]

Hmm interesting.
Ill try and see if i can replicate tomorrow. Might be to do with decompressing the languages wanting the CPU at the same time as PD.

Will have a look and see what I can find when I get time

[Johnex]

It's probably just nit picking honestly 😅, just something I observed.

[Ralim]

Its a hint something isnt optimal so work at least a quick poke :)

[Johnex]

I guess we can lock this unless anyone else finds any issues 😎

[publicarray]

👍 confirmed working on the ACC SC7A20. Thank You!

I got a warning saying some settings had changed. The message was displayed for a long time too, I thought the pinecil had hanged
showed for like 5 seconds

If I press the - button (closest to the USB-C port) I can dismiss the notice immediately. (the other button might work but did not test it)

[Ralim]

Ohh, I interpreted that as it hung ignoring button presses.
A button press indeed is meant to dismiss it or it times out after 5 seconds.
@Johnex did you try a button press ?

Excellent glad its working properly now 😓 that was a fun one to figure out (bugs hiding bugs)

[Johnex]

No I never tried the button, I just guessed it would go away on it's own 😁

Thanks for all the hard work! 🤗

[Ralim]

Ah well that explains it 🤟🏼
All is good then, will get these fixes a bit more tested and then do a new release soon

[Johnex]

Sounds great, this will be an awesome release 😎