FYI. There is a USB enumeration prolem on the RPi 3B+

[rogerclarkmelbourne]

Hi Andy

I'm investigating a problem with the USB based Zumspots on the RPi 3B+, where the USB CDCACM device is not showing up.

I'm pretty sure the problem is the length of the USB reset pulse (in IOSTM.cpp) as increasing it from a count of 512 to 1024 seems to fix the problem.

But I need to do some more testing.

Also I think the bootloader may need to be modified, as I don't think even if I change MMDVM_HS so that the modem shows as 1EAD:0004 after switching into the main application. I think that the update won't work, because the bootloader USB device is not showing up following the soft reset into the bootloader

Anyway. I'll give you another update when I have a full solution

[juribeparada]

Hi Roger, thank you very much to see this issue. I don't have a RPi 3B+ for testing, then I will wait for your results.

[rogerclarkmelbourne]

No worries.

I have fixed the problem on a Zumspot USB by changing the delay to 1024 (from 512), but I think the delay is probably now much longer than it needs to be.

I will try some other settings e.g perhaps 768 may OK. And let you know what the optimum value is.

BTW. Making the pulse too long also causes issues, since ultimately this method to reset the USB bus is a hack/ work-around, needed because the BluePill board does not have any USB reset circuit (unlike the Maple mini board etc)

[rogerclarkmelbourne]

Andy

FYI. I think the problem may be more to do with the bootloader than in your firmware.

I just changed the USB delay back to 512 and it still seems to be OK, but I am running a modified bootloader.

So potentially just replacing the bootloader fixes this,

I'll let you know when I have a definitive answer

[juribeparada]

OK, I will wait for your new bootloader. People will need to replace bootloader in order to work with RPi 3B+.

[rogerclarkmelbourne]

I've done some more tests and its very odd.

My RPi 3B+ is now working OK with the old firmware, yet last week Ki6Zum and VK4TUX reported the problem to as their 3B+ would not work.

I tested on my B+ and I had the same problem.

i.e if you type lsusb, it shows the Zumspot USB as 1eaf:0003 instead of 1eaf:0004

I will need to reload Pi-Star onto a clean SD card and try again, as I suspect some change I made to the Raspberry Pi OS may also have an effect

Hopefully Ki6ZUM (Jim) will be able to do some tests today (Sunday in the USA) and confirm if my changes fix the problem on his 3B+, but I will also get him to revert to the old firmware and retest etc

[rogerclarkmelbourne]

Andy.

I'm now having problems replicating this problem.

It could be something crazy like the length of USB cable, effecting the B+

I'll close this issue until I have more details

[vendra]

@rogerclarkmelbourne Hi Roger, I am having the same issue with a blue pill and a RPi3B+ running on Ubuntu Mate 18.04 arm64.

I am trying to establish connection between the two but I couldn't. I tried a much shurter usb cable and now I can see the device through lsusb (I see leaf:0003) while with the longer cable it was just undetected.

I expeceted the /dev/ttyUSB0 to pop up but I was not lucky. Let me know if we can work on this and find a solution!

EDIT: Using "dmesg" I found I may be having undervoltage problems, in that case the cable length might play a role.

[ 6158.059709] usb 1-1.1.3: USB disconnect, device number 15 [ 6159.114758] Under-voltage detected! (0x00050005) [ 6165.162958] Voltage normalised (0x00000000) [ 6175.243264] Under-voltage detected! (0x00050005) [ 6176.075245] usb 1-1.2: new full-speed USB device number 16 using dwc_otg [ 6176.177923] usb 1-1.2: New USB device found, idVendor=1eaf, idProduct=0003 [ 6176.177940] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 6176.177951] usb 1-1.2: Product: Maple 003 [ 6176.177960] usb 1-1.2: Manufacturer: LeafLabs [ 6176.177970] usb 1-1.2: SerialNumber: LLM 003 [ 6181.291468] Voltage normalised (0x00000000)

Are you getting the same output? I will try with a different supply

EDIT2: Midnight update: I unplugged an USB dongle for a wireless kb and mouse. Now I am powering the bluepill through an external battery. With lsusb I can see it as leaf:0004 and ttyACM0 is created when I plug in the device.

Federico

[rogerclarkmelbourne]

This is a known bug on the 3B+

It’s a timing problem with the length of the reset pulse imposed on one of the USB lines ( I think possibly USB D+) used to signal that the USB device being provided by the BluePill has changed and the host needs to re-enumerate it’s USB bus.

The B+ seems to need s much longer pulse than any other hardware, but if the bootloader and MMDVM HS are changed to lengthen the pulse, the code won’t work on the other PRi boards.

However, Andy may have found a workaround that works for all boards

[vendra]

This is a known bug on the 3B+

It’s a timing problem with the length of the reset pulse imposed on one of the USB lines ( I think possibly USB D+) used to signal that the USB device being provided by the BluePill has changed and the host needs to re-enumerate it’s USB bus.

The B+ seems to need s much longer pulse than any other hardware, but if the bootloader and MMDVM HS are changed to lengthen the pulse, the code won’t work on the other PRi boards.

However, Andy may have found a workaround that works for all boards

Thank you. Anyway I was able to connect using a shorter cable and powering the bluepill using an external battery. See my update on the previous post for details.

I tried to switch back to the longer cable but it's not working again.

[rogerclarkmelbourne]

Interesting....

Problems with cable length is often more to do with the supply voltage than the timings, especially considering that the length of the reset pulse had to be increased significantly e.g. 10's of millisconds to make it work on the B+, and a cable should not introduce that much Line Delay

[dave31418]

I see this thread is closed. Was this resolved in another thread? This is kicking my butt. Oddly I can make mine work on a Pi 3B+ but not a Pi Zero or Pi 4. I would just like to know if a resolution was found that makes this work across all PIs.

[rogerclarkmelbourne]

@dave31418

AFIK, Its not possible for one version to work on all RPis, because something is different in the 3B+ USB system or hardware, which requires an extra long USB reset / enumeration signal.

I know they have tried to tune the reset pulse length so that it works on all RPi boards, but I'm not sure it was every 100% successful, or even 50% successful.

Fundamentally this is actually a hardware design fault on the STM32 board, because the USB reset / enumeration hardware is not correct, but the workaround to send a fixed length pulse works on virtually all hardware , including PC's and Macs, except the RPi 3B+

Nevertheless, whatever they did when they designed the 3B+ made it incompatible.

[dave31418]

Thank you Roger. My issue really isn't with the 3B+. I have better luck with it than the other permutations. For me the problem is the PI Zero and PI 4. I have a fist full of Blue Pills that exhibit the same odd phenomena. Oddly some work on Pi Zero and some don't. It is a mystery as to how these are different. I know some have a Chinese clone of the STM32. Also oddly those seem to work more consistently than an authentic STM32. ( this is a shame ) I have a Zumspot USB which works EVERYTIME and on every thing. This too is a bit of a mystery as to why. So I'll plug away at this a bit more as I want to have a root cause understanding why some work and some don't.

[rogerclarkmelbourne]

OK.

I can't remember if I tried it with the Zero or Pi4. Almost certainly not the Pi4

Did you check the USB pullup resistor. Most STM32 boards from china use a 10k resistor, for this, but the correctly value I think is 1k or perhaps 1.5k. I recall the fix is to put something like a 1.5k resistor in parallel with the SMD resistor on the PCB, but I'm afraid I can't remember the easy way to do this.

Search on the web and no doubt someone has written an article etc about how to fix that problem.

Re: STM32 clones

Yes. They are a big problem, and it depends on whether the board has a legitimate clone or possibly a chip that failed testing in STM's factory, as a lot of partially defective chips seem to be getting into the supply chain from somewhere -- most likely out of the back of a STM factory in China.