Tried searching (maybe not extensively enough) and couldn’t find this - having USB connectivity issues with an R4 minima clone board. In general I’ve found that it tends to bug out more than an official board, many times giving “exit status 74” and I can get it to work again by double-pressing the reset button. But this is new to me - it’s recognizing the board name, but I’m getting a cube icon next to it instead of the USB symbol, and I’m not sure what the “1-1” under the board name means.
I’ve been trying the usual suspects (different USB port, double press reset button, restart IDE) but keep getting back to this point. Apologies if this is documented somewhere and I just couldn’t find it, or if the answer is just “don’t use crappy clone boards,” but I’d at least like to know what’s going on.
IDE 2.3.8 on Windows 11, just updated this morning.
What does Windows device manager think of your board?
The R4 Minima uses native USB for communication with the PC. Bugs in your sketch can cause the board detection to malfunction (not recognised or not able to upload). Does your problem also happen after uploading an innocent sketch like blink of an empty sketch.
What are the other "unknown" COM ports? Do they disappear when you disconnect the Uno R4.
I also had a USB wireless mouse plugged in. Unplugged both that and the Arduino, restarted IDE, COM3 and COM4 are still there.
I can usually get Blink to work but sometimes still need to cycle USB/power before it will connect again.
The problem started when I modified the capacitive touch code on this page to add a 2nd pin: UNO R4 Capacitive-Touch Tutorial | Arduino Documentation, so I am going to revert back to that point and see if I can reliably reproduce the error. It worked fine (no upload issues and code worked as expected) with the code on that page for just one pin. I don’t see anything on that page that says “you can’t do this with more than one pin at once,” so it could be a coincidence, but maybe that’s the source of the issue. Sorry I didn’t include that information in my original post.
This port is the DFU (device firmware upgrade) interface produced by the board.
Although serial ports are most common, Arduino IDE actually supports the use of any arbitrary communication channel between the PC and the board as a "port". This includes DFU interfaces.
UPDATE - I am able to reliably reproduce the error by commenting out the if/else statement in the setup() function of the capacitive touch example code. If I comment out that statement, then the IDE output gets all the way to “done” when compiling the code, but then it hangs on upload, and the Windows “USB device not recognized” warning pops up. I’ve pasted the code below. I guess I’m misunderstanding the touchButton.begin() inside the condition for the if statement - it looks like that command must be called (and will evaluate to true and work in an if statement?) to initialize the sensing? I (mistakenly) viewed that if/else statement as an optional error check that I could comment out if I knew I was using a compatible pin.
(typing this as I need to head out the door, can follow up with more details tomorrow if needed)
The tricky thing about the boards like the UNO R4 Minima that use a native USB capability to communicate with the PC is the code that creates the USB CDC serial port is running on the same microcontroller as your sketch. This means your sketch code can break the USB code, or stop it from running. When that happens, the board no longer produces a serial port.
That is what happened here. When you tried to read the capacitive touch sensor without first initializing the library, it broke that USB functionality by crashing the sketch program,. That causes the board to go into the DFU mode where it no longer produces a serial port, but does still provide a DFU interface.
It is mandatory to call touchButton.begin(). It is not mandatory to check the return value of the function. So if you prefer, you could change this code:
if (touchButton.begin()) {
Serial.println("Capacitive touch sensor initialized.");
} else {
Serial.println("Failed to initialize capacitive touch sensor. Please use a supported pin.");
while (true);
}
To this:
touchButton.begin();
However, I do think it is best to check the return value. As you discovered, if the initialization fails, it can cause a confusing program crash. The whole point of the check is to detect that situation, communicate the nature of the problem, and avoid the crash state.
@ptillisch ok, thank you, that’s very helpful. I think I need to clear up my understanding of what happens if you do an assignment operation or call a function inside the condition for an if statement, as opposed to a comparison operator. I realize I could probably look this up, but in the age of AI, it’s nice to ask a real human for an explanation :-). For example, I’m used to
if(x==2){ // do stuff }
but I’m not clear on what happens if I write
if(x=2){ // do stuff }
In that case, does the expression in parentheses still evaluate to true somehow?
or
if(someFunction()){ // do stuff }
as with our touchButton.begin() example - does it depend on what the function returns? Will it always be true if the function runs without crashing?
Assignment operations are expressions that can be evaluated. That means that the assignment itself has a value, and -for fundamental types- this value is the one assigned in the operation.
The value zero [...] become false. All other values become true.
So if any value other than 0 is assigned, it will evaluate as true. If the value 0 is assigned, it will evaluate as false.
My advice is to write more verbose code that is more clear. In this example:
x = 2;
if(x != 0) {
Obviously this specific code is silly since there is no need to evaluate the known value of x. But you can extrapolate this to other applications that are completely valid.
Yes.
No. It evaluates the return value of the function call. It is equivalent to this;
@ptillisch actually, one last follow up question - is there any guidance or what type(s) of error(s) may be more likely to cause this type of USB communication issue on the R4? In this case the code compiled just fine, so I wasn’t really hunting for an “error.”
I’m a K-12 curriculum developer and we do a lot of customer support - usually it’s “this breadboard wire is in the wrong hole” for hardware issues, or “make sure you have the right board selected from the drop down menu” when the code won’t upload, but I didn’t have “an error in the code could prevent it from uploading” on my radar. So if there are any more specifics about what type of error could lead to that problem (as opposed to other errors that will show up when you try to compile), it would be helfpul.
Unfortunately this is caused by a runtime fault, not a compile time error. So you won't necessarily find any hints about the cause of the problem in the output from compiling the sketch.
It is worth enabling compiler warnings and evaluating them in case they will lead you to the bug in the code:
Select File > Preferences... (or Arduino IDE > Settings... for macOS users) from the Arduino IDE menus.
The "Preferences" dialog will open.
Select "All" from the "Compiler warnings" menu in the "Preferences" dialog.
Uncheck the box next to "Show verbose output during: ☑ compilation" in the "Preferences" dialog. ⓘ This is done because the verbose output is not of value for in this case. Its presence would only make it more difficult to read the potentially valuable compiler warnings.
Click the "OK" button.
The "Preferences" dialog will close.
Open the sketch that produces the "no serial port" symptom in Arduino IDE.
Select Sketch > Verify/Compile from the Arduino IDE menus (or click the ✓ button on the Arduino IDE toolbar).
Wait for the compilation to finish successfully.
Now carefully examine the contents of the black "Output" panel at the bottom of the Arduino IDE window. You might need to scroll up to see it all. If you see any warnings there, evaluate them to determine whether they might indicate a bug in the sketch code.
An important thing to understand is that a given warning doesn't necessarily indicate a real problem. It is only the compiler telling you that there is something that might possibly cause a problem under certain circumstances.
Unfortunately Arduino developers tend to write code that works as expected, but produces compiler warnings (this is the reason why warnings are turned off by default in Arduino IDE). So you may have to sift through warnings that were produce by code other people wrote in order to find the ones for the code you wrote. When it comes to your own code, it is a good idea to always adjust the code that produces a warning so that it no longer does so, even in the case where the code that generates the warning works as expected. The reason to always fix warnings is that it will make it easier for you to spot any newly introduced warnings that do indicate a serious defect in your code. If the compilation output is littered with innocuous warnings, you are likely to miss the important ones, or just stop paying attention to this valuable information from the compiler altogether.
