I'm struggling to understand why I am not finding more information about the best approach to handle the native USB Serial port on an H7, in my case, on a Portenta Machine Control device. After hours of trying to determine why any simple Arduino Portenta example for Ethernet connectivity hangs when the USB cable is removed from the device - the problem being Ethernet related was a red herring. Finally, commenting out all the Serial.* statements in my code, fixed the problem.
So - what is the standard approach for the typical Arduino "Serial.print" debugging approach, if Serial.print statements will brick the current running code if the USB cable is not connected? I may look at my own code at the moment to see if I can easily detect the condition, and skip the print statements, but I would expect this to be handled better by the Arduino core for the mbed devices. Removing all the Serial.print statements from a large codebase, so you can run it with the USB disconnected, is not practical, nor does it promote an Arduino standard usage.
Am I missing something here???
1 Like
Serial.print() and similar functions are non blocking
but maybe on your code you had while (!Serial.begin()) which waits until the serial monitor is open, to jump onto the next line of code
Not familiar with the Portenta but reasonably sure that it's the while(!Serial);.
That basically blocks till a communication channel is opened as mentioned above.
If it's anything like a Leonardo/Micro etc you have to be careful; disconnecting USB after the communication channel is opened can bring your board to a near grinding halt because it can not get rid of the data that you're writing/printing. To prevent that you will need to use Serial.availableForWrite() around all write/print statements and check if there is enough space in the software buffer to write the data. Analysis: Serial.print on Leonardo very slow after disconnection from serial - #7 by sterretje.
@PMarquinez, as said I'm not familiar with the Portenta. But on AVR boards Serial.print can become blocking; is the Portenta different?
@sterretje I cannot answer with a technical reason that backs me up right now
But Ive been using for years serial prints on the portenta H7 and similar boards running mbedOS and never had any failure or halt like the issue you mentioned.
Also I almost not worked with the Leonardo board.
I have some more info... after tinkering some more, this morning, the issue was occurring when USB had been connected and then disconnected - regardless of the existence of the While(!Serial.... check in the setup. Eliminating the check AND rebooting the Portenta after disconnecting the USB is they key.
So - @sterretje, I think you are dead-on on with your explanation.
That being said - While I have figured out how to get this working, I stand by with my opinion that this behavior is unusual to anyone without experience with this particular setup (ie, a native vs hardware port). I would consider myself quite experienced with amtel and "teensy" programming, but this threw me off a bit.
The only reason why you use while(!Serial); is so you do not miss the first output.
As long as you print without USB connected there is no problem; the underlying 'stuff' knows that there is no communication channel open. Once you connect the cable, the underlying 'stuff' realises that it can print; but it does not realise that the communication channel is gone when you disconnect the USB.
Could you share the sketch?
@PMarquinez
Here is a simple example.
uint8_t ledState = LOW;
void setup()
{
Serial.begin(115200);
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN, ledState);
}
void loop()
{
static uint32_t cnt = 0;
Serial.println(cnt++);
ledState = !ledState;
digitalWrite(LED_BUILTIN, ledState);
delay(100);
}
Arduino externally powered and connected via USB.
Above sketch uploaded.
Open serial monitor.
Observe L-LED.
Remove USB (serial monitor still open).
Note the slowdown of the blinking of the L-LED
You can add a while(!Serial) if so desired.