Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 9 months ago.
USBSerial stop working after first connection
Hi,
I've been playing with USBSerial along with raw Serial thru UART, all in the RTOS context. I'm instantiating the USBSerial with connect_blocking=false so that all code is working if I dont attach picocom to /dev/ttyACM0 at startup. The code is outputing prints thru both UART and USB while flashing leds in the mainloop. At the first connection to /dev/ttyACM0, everything is working, both UART and USB, but as soon as I quit picocom and try to comeback to /dev/ttyACM0, nothing is outputted anymore. Also, if I don't connect to /dev/ttyACM0 right at the beginning, it will block at the first usb.printf() although I've mentionned connect_blocking=false. Is there a way to make USBSerial really Non-Blocking ?
I'm experiencing the same thing under Windows. First connect is fine for both directions. Second connect will get packets on the OUT endpoint, but nothing comes back to the PC on the IN endpoint.
The curious bit is if I tick then untick the hardware flow control after opening the port a second time, everything starts working again.
posted by Bob Recny 03 Feb 2015Hi Bob,
Do you mean simply switching handshake hardware flow in your terminal ? You gave me a good idea : for picocom, switching flow didn't work, but changing baudrate does (char size too) ! Really strange ... Probably it is waking up the USBSerial somehow ... I will try to see if attaching a callback can help ...
posted by Martin Ayotte 03 Feb 2015Hi Martin, How did you go with this?
posted by David Godfrey 09 Feb 2015Hi David, I didn't found solution yet. As Bob mentionned, the OUT endpoint is still working, but not the IN endpoint back to PC until I either change baudrate or charsize of the terminal. I still think it is a bug related to USBDevice implementation in mBed, because I have similar setup on a STM32F4 (not under mBed) and I don't face such issue. I could try to implement code borrowed from STM32 to my LPC1768, but it will take much more efforts.
posted by Martin Ayotte 09 Feb 2015I'd be interested in a solution to this problem. To get my LPC1768 mbed to successfully send data in both directions I had to remove the checking of "terminal_connected" in USBSerial::_putc which is a very dirty hack and not something I'm even comfortable admitting to doing, but maybe it might be a pointer in the direction of the real issue.
posted by Jim Patterson 26 Mar 2015