Hi,
I'm working with uVision 5.15 and RL-USB with RTX to develop a USB CDC application. I used the function USBD_CDC_ACM_DataSend to send data over the USB com port. The application continuously (250ms step) sends a keepalive message through the USB com port to the host, the problem is that if the com port is closed after some messages the USBD_CDC_ACM_DataSend stops to work and also return 0 as byte sent, also opening the connection does not solve the problem. Someone knows how to solve this problem? Is this a RL-USB bug?
Regards
> I'm working with uVision 5.15 and RL-USB
Sound like you are working on the old RL-USB using the latest MDK-ARM. The RL-USB interfaces and implementations had changed a lot at MDK ver5.0 USBD_CDC_ACM_DataSend() was replaced with USBD_CDC_ACM_WriteData()
Differences to RL-USB http://www.keil.com/pack/doc/mw/USB/html/usb_diffs.html
I remember we had discussed on a problem of the OUT (host->device) endpoint at buffer full in the CDC of the old RL-USB. www.keil.com/.../ I'm not sure, the IN (device->host) endpoint would also have any problem.
> if the com port is closed after some messages the USBD_CDC_ACM_DataSend stops to work and also return 0 as byte sent,
Maybe your PC is a Linux (or Mac) box, which polls the CDC bulk IN endpoint just while the COM port opens. Windows CDC driver always polls the IN endpoint, regardless of open/close of the COM port.
A couple of workaround suggestions, a) Endpoint status Your firmware may read out the endpoint status directly from the USB hardware register. This method depends on your MCU, tell us the type number of your MCU for further discussion. While the IN endpoint is still occupied by the last packet, don't call USBD_CDC_ACM_DataSend().
b) DTR signaling to know open/close of COM port In most of OS, PC serial library raises DTR at COM port open, it drops DTR at close. If your library wouldn't, your PC application could explicitly flip DTR signaling at open/close. Your firmware can catch DTR change by USBD_CDC_ACM_PortSetControlLineState() callback. While DTR drops, don't send the heart-beat message.
Tsuneo
Sound like you are working on the old RL-USB using the latest MDK-ARM.
Yes, I'm using the old RL-USB.
The PC is a Windows PC. I have already saw that with Linux OS this problem exists and I used the DTR signal to check the connection status and avoid data sending if the com port is closed.
tell us the type number of your MCU for further discussion The MCU is the LPC1758 from NXP.
After a lot of tests I restricted the problem at the OS reboot (still Windows), during reboot the com port is closed and the device put in suspended state. After the reboot the device is resumed from suspend state, the com port has been opened, the device detects the DTR signal and start transmissions but sometimes the transmission seems to be blocked. What I saw in debug mode is that the device receives SOF events, calls routines to tx on USB data but there are no BULKIN events and nothing is received from the PC side. After some packets the intermediate buffer becomes full and this is the reason why USBD_CDC_ACM_DataSend returns always 0.
I tried also to replace the USB lib from Keil with the one found here github.com/.../USBStack which seems to be the source code of the libs but I didn't found where is the real problem.
Hello,
I need to ask is the problem solved?
But at first, I working with Keil uVision Version 5.18, CMSIS 4.5.0 and MDK 7.0.0. The used microcontroller is a LPC4357.
I have the same problem with the USBD_CDC_ACM_WriteData Function that returns over the time always a zero value. When I send not big amount of data over the short period of time, then this function works fine, but in the case of big amounts it stops working after some time. In my case I am waiting for the DTR-Signal and after the Signal appears, I start with the data Transfer over USB to Windows PC. And DTR-Signal has the same state all the time, it is not toggled.
Best regards, Daniel Huhn
Hi Tsuneo! How can you set the control line for USBD CDC? I've asked similar questions https://community.arm.com/developer/tools-software/tools/f/keil-forum/47289/lpc1768-architecture-questions . I'm working with the VirtualCOM USBD sample for lpc1768, I can connect to the PC but can't seem to read data that I send from the MCU to the PC in C#. I can however, using teraterm. Any hints at what might be wrong?
Kev said:can't seem to read data that I send from the MCU to the PC in C#. I can however, using teraterm
Check your control signal settings - DTR, RTS ...
You could also use something like https://www.eltima.com/products/serial-port-monitor/ to see what's happening at the PC end - and where you C# differs from Teraterm ...
EDIT
I'm not affiliated with nor sponsored by Eltima - but I have used their Serial Port Monitor with success in debugging such things.
If TermTerm can read/write on the PC side, then it's probably your code rather than the VCP/CDC
Look for other examples, and try those, don't see your code so can't suggest what's wrong there. In C one typically needs to use CreateFile() and Get/SetCommState(), data can then be moved via Read/WriteFile(). If the port is truly virtual the baud rate has no real meaning/effect.
Given the age of the LPC1768 I'd have to imagine there are several VCP/CDC class examples that could be found, along with the expected set of functionality and descriptors.
Great idea man thanks keep it up all the time. am very happy to see your standard. MyAARPMedicare Login