usb connection issues #265
Comments
|
Thank you for the information. I have received some reports, but I have not yet been able to identify what the cause is. I will review some of the design policies and try to improve them. |
|
if you need any further information or have an idea how to fix existing pcbs I'm all ears! |
|
@xkonni can you let us know the distro and kernel versions please? |
|
sure, here are my 3 test computers
|
|
Is yours cherry or chocolate? |
|
I got two 4.1 here, one cherry, one choc. they behave exactly the same. On a usual day they work. Does not matter which one I use. Then after a while the usb issues appear. Changing usb from left to right does not help, switching cherry to choc does not help. A cold boot sometimes helps. |
|
Thank you for sharing the details! |
|
I’m also experiencing some disconnect issues with my Core v4.1. When I plug it in and use it to practice on keybr.com, it works well. However, if I set it aside (while it’s still plugged in), switch to browsing, or use my Mac keyboard, the Core v4.1 stops responding when I try to use it again, even though the LED remains on. Tell me if I can help somehow troubleshooting... |
|
I'm having similar issues as well. Seems to be that the non-plugged side disconnects most often, but sometimes I'll get disconnects on the plugged in side as well. I saw the LEDs flicker when this happened, which isn't suprising, but it was a series of very short bursts of flickers which makes me think it's a Power-related issue. |
|
This is just a guess, but from some reports I've heard it seems to be a power supply issue. There are some parts that are not very well designed, and some of them may be defective. I'd like to isolate some of the root causes, and I'd appreciate any information you could give me.
|
I've had the issue on a Mac. I do have a spare PC that I can test with later this weekend and report back. No spare Corne v4.1 keyboards assembled to test with easily. |
|
Update: Set up:
I used the Corne V4.1 all day today, about 10 hours of use during work. I experienced a total of about 10 losses of function, some back to back, with varying amount of time between them. Left hand (slave side) had about 6-7 losses of function. Right hand (master side) had about 3-4 losses of function. On one occasion, losses of function occurred every 30 seconds and required the keyboard to be reflashed. Each time there was loss of function, it was preceded by LED flickering. Hope this helps! I'm happy to set up more Corne V4.1s to test in varying conditions. |
|
Another update: I swapped my keyboard out with another Corne v4.1 PCB this evening. I did this to verify that there were no hardware issues with the first PCB. I also used the same firmware to avoid SW variation. I confirmed the same behavior with keyboard lockup on one side resulting in requiring a power cycle to recover. This is a big issue! Right now I can't use my (5) Corne v4.1's nor can I use a v4.1 as my daily driver with these reliability issues. @foostan have you looked into this any further? |
|
Thank you for your confirmation. Unfortunately, this problem does not occur in my environment, so I cannot investigate further. |
|
Hi, How can we help you further investigate this issue? edit: |
|
FYI the second USB port will work (opposite hand) however your special keybinds may behave differently from your custom layout; found this to be a pleasant surprise considering a USB port joint was damaged on mine and the opposite ha d allows me to work around the one broken USB jack. |
|
Another possibility is that the PCB is simply damaged. Please also contact your supplier for further information. |
|
@foostan 4 different PBCs from 2 different vendors show the exact same exact issue, both used as a pair and as a single unit (with a custom firmware). I had spent quite a lot of time trying to debug and i'm 100% positive it's not a single unit, it's not my computer, the usb cable or simila. What i'm hoping to get here is some help in further debugging what is an issue with the USB on the keyboard, and hopefully find a solution/workaround to help the other user that may have the same issue. So, in that light, is there any other info i can provide? @chadhakala no, the usb port is not damaged at all. |
|
Thank you for sharing the details. I'm glad you're being helpful. So what you're reporting means is that the issue is more likely to occur with KMKfw than with QMK? I'll give KMKfw a try. Thanks again. |
|
@foostan I don't think he's saying the KMKfw is worse, but rather by testing the same firmware on a generic RP2040 and on the Corne v4.1 board, the issue is only present on the Corne v4.1. This eliminates as many noise factors as conveniently possible. The help needed is some debugging on the Corne v4.1 USB HW design to understand what's unique to the design that's causing the issue. Please let us know if you need data. I am fully willing to support as needed. I would love to help solve this. |
|
I'm sorry, of course. I didn't mean KMKfw is worse. I would like to isolate the problem and investigate the cause in detail. Thank you for your cooperation. Let's share information on this issue. |
@alessiocurri My apologies--I didn't realize this thread was all about the lockup; while,I have faced this issue and other unique issues for which I do not have systematic evidence for being a USB fault. The last time I used the corne I did face this exact lock up issue and stop using it completely for that reason, I am following all these threads so my apologies, little embarassed for chiming in didn't even read the full thread; I'm pretty sure I meant to respond to a different comment in the thread and was unaware there was even an issue for lockup. |
|
@dahmwern exactly what i meant ;) @foostan here https://gist.github.com/alessiocurri/18e6b0c48a74c37dee766a71a22ac62a you can find my config for a left-only corne 4.1, no TRRS cable nor right side necessary. To install kfmfw I just copied the kmkfw files from the github repo, added the neopixel.py library (you can also use the .pyc, it should be the same) and my code.py and boot.py (the latter is not strictly necessary). Please note the default layer is empty. To test you need to switch to another layer, the leds will highlight the active keys. In this config i can replicate the usb lockup on average in 20 minutes, using all 4 boards (tested without the switches, with, no difference). The easier way to check the status is to use a serial console con the virtual com port exposed. There you can find the python REPL. That virtual serial port will disappear when the usb issue presents itself. @ChadHacksaLot no prob at all, probably it's me owning an apology... in my reply i have been very blunt, probably a tad much :) |
|
Just wanted to add that I'm experience what sounds like the exact same issue with my corne v4.1. Same behaviour everyone above is describing - sometimes one side becomes unresponsive, sometimes both, sometimes it works nearly all day, sometimes it's only seconds or minutes until the next lockup after disconnecting and reconnecting the USB cable. One time, the right side even changed colour to the pattern pictured below: Same behaviour when plugged into
I absolutely adore this keyboard when it works, I would love to assist in some way. I have career experience in PCB design and experience in micro-controller firmware programming - let me know what I can do to help or point me in a direction please :) |
|
@viscount-monty I've experienced that same LED pattern during lockup. Your description is consistent with my experience. What information do you need to analyze the PCB design for potential USB related comms issues? |
|
It seems that it may or may not occur depending on the environment. I don't know under what conditions it occurs, but has anyone noticed any electrical abnormalities when the problem occurs, such as a short interruption or a significant drop in voltage or current? |
|
Considering the current case, the distance between the IC and the USB doesn't seem to matter much, because this issue also occurs at one side which is not connected USB. |
|
If you are familiar with the SWD interface and can reproduce the failure, you may be able to power the board via the OLED header, connect to SWD and see if you can get the MCU to fail without any USB connection present at all. |
|
@george-norton i tested this with circuitpython and a simple program that light the leds in sequence: when the USB goes down, the mcu is still running fine. @foostan I'm an hobbist in this field (electronics), so this is a bit of guesswork. |
|
@george-norton You are right. It would be beneficial to rule out other causes. I assume this could be tested my running the RP2040 with some testing C or Python code, just logging the behavior via the debug serial header. For this test, the USB lines should be fully deactivated, (disabled GPIOs) to mitigate interference. I also assume the error codes could indicate the problem we are facing here.
The main reason I mentioned this was, that the design is not within the specification for routing USB lines. This does not say it has to be a problem, but is certainly one of the first areas to look at when problems like this occur. |
|
I tested the case printed with conductive filament but, as expected tbh, there was no change. @foostan while you investigate, i think you should add a warning in the readme.md file about this issue. |
|
Add a notice about this issue on README https://github.com/foostan/crkbd?tab=readme-ov-file#notice |
Thanks for including that notice @foostan 👍 are you able to test a board with an @george-norton raises a very valid point regarding the crystal load capacitance. The source to which he is referring is pictured below Having said that, my understanding of @alessiocurri 's reports are that he observes both RP2040 devices remaining functional (changing LED colours on both sides) after they have experienced a USB disconnect due to phone EMI. I will attempt replicate those results, and look into the excellent debugging suggestions by @george-norton and @fabianmuehlberger
I also have a bunch of Pi Pico/W units with various dev boards and sensors, I will see if I can replicate the issue on any of those! |
I had not considered it properly. I'll look into the Abracon ABM8-272-T3 and other options. I investigated the EMI effect of a mobile phone on Cornelius v2. This board is not a split keyboard, but it uses the same circuits and parts. The investigation resulted in the USB connection being cut off and locked, just like the Corne v4. This shows that the problem is not with the USB-related wiring or part placement but with the selection of parts or the circuit design. By the way, the Cornelius is an aluminum body, so I don't think this will actually be an issue. |
Rather than visually observing the LED, you could just output a high frequency and meassure it. (basically what an LED does ;) so you can just hook up an oscilloscope to it :) |
|
I found that the Cornelius board and the Corne v4 board have some different characteristics. I was able to cause the problem with Cornelius yesterday, but since then I have not been able to cause any problems. On the other hand, I have been able to cause the problem many times with Corne v4. This means that Corne v4 is very unstable compared to Cornelius. In addition to the part selection and circuit, it suggests that there are problems with the part placement and wiring. Placing a mobile phone right next to the RP2040 and a Corne v4 crystal immediately causes the problem. On the other hand, no problems occurred when moving the phone close to the TRRS connector. It seems that the noise is significantly reduced even if you talk about 10 cm away. The RP2040 and crystal are placed at the very edge of the PCB, so it is possible that they are easily affected by external factors. Simply shifting them to the center may have an effect. By the way, would it be okay to make the DC-DC converter and Flash memory parts smaller? The current parts are too large and there is little freedom in placement. Doesn't it need 128M of Flash memory? |
|
There are small form factor, large capacity flash parts available. See C2843335. |
|
I'm changing the position of RP2040 to the center of PCB. |
|
@foostan may I ask why you didn't go for a ground plane pour on both sides of the corne? The image you posted of the Cornelius appears to show a ground plane pour on the micro-controller side, though it seems to lack any 'stitching' vias. If there is no ground plane pour on the other layer that would make sense though. I'm not certain it would make a difference, but I'm used to seeing/designing RF boards with top and bottom ground plane pours, stitched with vias at reasonable intervals. Example: |
|
@viscount-monty Can you tell me what its significance is? I didn't do it because I didn't know what effect it would have. |
Instead of a pour on top an bottom, I highly recommend making a 4 layer board. The top layer is segmented due to the lines, having a solid inner ground would be beneficial.
|
|
I have already verified the four-layer design and prototype. Although the wiring has certainly been simplified, I have concluded that the benefits were not enough to justify the increased costs. |
|
@foostan Certainly - proper grounding/shielding prevents EMI, either emitting RF which could interfere with other devices, or shielding the device from other source of RF interference. Similar to how a co-axial cable features a shield/ground which entirely covers the signal conductor. This kind of grounding/shielding is required to make RF PCBs function correctly and pass compliance testing. To think of it another way, a PCB trace could accidentally behave as an antenna for external interference if not shielded/grounded sufficiently. |
|
So, let's put a ground around the edge of the board as much as possible. That alone will have an effect. As mentioned above, I will not use a 4-layer board. |
|
The latest board is here. I'll confirm again and create a prototype.
|
|
Nice work, looks great! I'm looking forward to hearing how the prototype turns out 🤞 |
|
Can't wait to hear the results. If you need other people to help you test your boards... Just saying :) |
Not quite. The USB lines should not be "as thick as possible" but rather have the correct impedance. Regarding trance length: For a high speed USB signal, a conservative approach for a 2 layer board (according to the article) would be to stay under the 25% limit, which is roughly 20 mm line length. Beside good shielding from EMI this is also an important factor for signal integrity. Below is a guide for 2 layer boards. |
|
Thanks for the detailed information and feedback. I will try to calculate the impedance and improve it. |
|
To make it clear: The impedance is not the only criteria for USB. Implementation according to best practices and hardware design guides as mentioned in other posts are critical if you want your product to be within the specification. This is a general overview of the EMC USB specification https://www.we-online.com/components/media/o109031v410%20ANP024d_The%20USB%20Interface%20from%20EMC%20Point%20of%20View.pdf If you plan to sell your product in the EU, you have to comply with the regulations described here https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en |
|
Just as an external comment, I've got an RP2040 based split board that exhibits similar behaviour when a mobile phone is placed near the board. (Fingerpunch ximi v2). I managed to reduce the symptoms significantly by using a shielded USB-C cable |
hi, not pushing just like to know how long does it take to make the prototype? |
|
I ordered it last week. |
|
Another temporary fix seems to be using a powered USB hub with EMI shielding. I've been using my Corne v4.1 for a couple weeks now through one without this issue, then today started plugging it directly into my laptop via usb C and the issue started. I'm gonna try a more shielded usb C cable for travel now. My details are the same as others have already stated: left split is plugged in via usb, right split connected to left via trrs. Phone gets close, the right split will stop taking input after a short period (but keeps rgb on with animation paused), and left still works. Have to unplug and replug for it to start working again, and then it will last anywhere from 5-30s depending on how close the phone is I guess. Issue goes away with enough distance. |
got 2 crkbd rev 4.1, love them, typing on my old 60% is a pain now.
but for some reason the usb connections on both devices are rather unstable on my machines (linux pc, 2 dell laptops with linux). first I thought it was a hw issue, but the second (one from a diy store in germany, one from aliexpress) shows the exact same issues.
using your firmware with the vial keymap. tried some options (remove
USB_SUSPEND_WAKEUP_DELAY, increase it, ...) but the devices remain unstable. sometimes they run for hours, then they fail every few seconds.Could this be related to #229 ?
any help is highly appreciated!
logs:
The text was updated successfully, but these errors were encountered: