My sketch on a DUE periodically sends a message to the host via native USB and reads the answer message.
The sketch has proper error handling, means it detects all kind of transmission errors and uses timeouts.
Nonetheless, the sketch freezes (easily recognizable since otherwise some LEDs are blinking all the time) if the USB port is disconnected, either physically or by taking the device away from the virtual machine in which the host program is running. This problem does not happen if the host program just quits (i.e. stops answering).
I could not find out where in the sketch the freeze happens. What I can say, it is not during the time when the sketch sends the message and waits for the answer until 15ms timeout (i.e. not within SerialUSB.readBytes or SerialUSB.write - and yes, SerialUSB.available correctly states 0 Bytes available, keeping my sketch off from calling SerialUSB.readBytes). However, the sketch, unable to detect the non-availability of the USB connection, continues to send messages to the host, while getting no answer. The freeze happens after 8 messages without answer have been sent, each 16 Byte. The message send period is ca. 30ms in that condition.
My conclusion of these observations is, that the freeze is within an interrupt, triggered by an event that is part of USB handling, or that there is a non-trivial correlation to other functions that I use, such as sending/receiving data on the serial ports - this is what my sketch does when it is not busy with USB traffic.
Can anyone give me some hints how to avoid the problem? If the sketch could detect that the USB connection has ended, it could stop sending messages - provided that would help. Testing the statement "(SerialUSB)" showed that it is always true, so this does not work.
I have been having similar problems with the native usb. I can't get a minimal code segment where closing the USB freezes the DUE (though I have seen the behaviour).
However, the attached code (arduino and computer-side python) freeze the arduino given the instructions in the comments. The is a minimal reproducible bug. The arduino is waiting for serial input, then starts blinking the LED on pin 13 after it has received the 'G' character on the serial connection. The serial connection is not used outside of setup.
On the client side, the 'G' character is sent to all available COM ports.
If I plug in the native USB and run the python spamG.py, the LED starts blinking as expected. When I unplug and re-plug the native usb, the LED stops blinking, and will not start again even if spamG.py is re-run.
SerialErrorReproduction.ino (1.13 KB)
spamG.py (742 Bytes)