Hi,
I'm trying to implement a CDC-ACM (CDC-232) using V-USB on a small atmega328p board. I've wrote my code inspired by cdc232.2011-06-24 archive from http://www.recursion.jp/avrcdc/.
It works fine in one direction but not in the other !
From gtkterm, I can send characters to the atmega328, and it is receiving it properly in the usbFunctionWriteOut() function.
The reverse direction is not working : as soon that one character is send to PC thru usbSetInterrupt() call in the uartPoll() function, the usbInterruptIsReady() funtion returns 0 forever blocking any further transmission to usbSetInterrupt().
To make sure it is not my own code that had something wrong, I've compiled the original cdc232.2011-06-24 archive, only changing the target CPU and the F_CPU, and I figured out it is behaving exactly the same way.
Notice that the receive pipe still working fine while the transmit is blocked.
Any idea ?
V-USB CDC-ACM stuck with usbInterruptIsReady() = 0
Re: V-USB CDC-ACM stuck with usbInterruptIsReady() = 0
I used that version successfully on an atmega8 at 12MHz (reprogrammed a USBasp). I notice that I switched to the most current usbdrv, not sure if that was necessary.
I'm on Ubuntu 12.04 and I used something like this to test, with the device's TX and RX connected together for a loopback test:
I'm on Ubuntu 12.04 and I used something like this to test, with the device's TX and RX connected together for a loopback test:
Code: Select all
# Configure serial
stty -F /dev/ttyACM0 sane
stty -F /dev/ttyACM0 raw 57600 cs8 -crtscts -cstopb -parenb -echo
# Capture output in background then send test message
cat </dev/ttyACM0 >capture &
echo "test" >/dev/ttyACM0
# Stop capture and examine result
kill $!
cat capture
Re: V-USB CDC-ACM stuck with usbInterruptIsReady() = 0
Hi blargg,
Glad to see your feedback that it is suppose to work. I presume you didn't have to do any changes to the original package ?
Unfortunately, it still doesn't work for me. (I'm running 12.04 too, so it should not be a driver issue.)
I've ran your test script, AVR is receiving string properly but capture is still empty.
I've even try changing the crystal from 16MHz to 12MHz to make sure the problem wasn't related to clock accuracy.
Then, I've done some debugging with "usbmon" and "wireshark" : I can see 16x "UBR_INTERRUPT in" been send when I'm launching gtkterm and been replied 16 times by the AVR with "URB status: Broken pipe (-EPIPE) (-32)". (running the test script is also doing the same returns, although not in the same packet order)
I've added a USB_RX_USER_HOOK to figure out that interrupts are calling usbProcessRx only for SETUP and DATA packets.
I've tried to dig into assembly code, but I'm a bit lot : I can't figure out where the -EPIPE error comes from and why, I didn't found a place where a reply packet have such status.
Glad to see your feedback that it is suppose to work. I presume you didn't have to do any changes to the original package ?
Unfortunately, it still doesn't work for me. (I'm running 12.04 too, so it should not be a driver issue.)
I've ran your test script, AVR is receiving string properly but capture is still empty.
I've even try changing the crystal from 16MHz to 12MHz to make sure the problem wasn't related to clock accuracy.
Then, I've done some debugging with "usbmon" and "wireshark" : I can see 16x "UBR_INTERRUPT in" been send when I'm launching gtkterm and been replied 16 times by the AVR with "URB status: Broken pipe (-EPIPE) (-32)". (running the test script is also doing the same returns, although not in the same packet order)
I've added a USB_RX_USER_HOOK to figure out that interrupts are calling usbProcessRx only for SETUP and DATA packets.
I've tried to dig into assembly code, but I'm a bit lot : I can't figure out where the -EPIPE error comes from and why, I didn't found a place where a reply packet have such status.
Re: V-USB CDC-ACM stuck with usbInterruptIsReady() = 0
Hi,
I've found this thread ...
viewtopic.php?f=8&t=1030
Is this still true that we have to recompile Linux kernel driver to make CDC-ACM working fine even after more than 5 years ?
I've found this thread ...
viewtopic.php?f=8&t=1030
Is this still true that we have to recompile Linux kernel driver to make CDC-ACM working fine even after more than 5 years ?