Hej! We build a box using TQ's BluePro (based on MPC5200, see www.tq-components.com) and a small switching device developed inhouse featuring an Atmel AT90USB162. The connection between both is cdc-acm, it transports a proprietary ASCII protocol (similar to Hayes). Everything is built together so both devices are powered on at the same moment and always connected. This works quite good once a connection is established, but depending on timings (?) establishing the connection is a problem. In these cases reading from /dev/ttyACM0 does return binary data without even sending a command in the first place. And it looks like commands aren't transmitted as the switching device doesn't react when writing one to ttyACM0. Removing the USB cable and reconnecting it fixes this. I'm trying to recreate the situation and take some logs. Unsuccessfully up to now. But I stumbled on another issue, some ping-pong of data, where I could take logs. The following is the result of a single $ (cat /dev/ttyACM0 | od -c) & $ echo \#VER > /dev/ttyACM0 c787f500 1382722508 S Bo:1:002:4 -115 4 = 23564552 c787f580 1382722635 S Bo:1:002:4 -115 2 = 0d0a ; end of "#VER" c787f500 1382722747 C Bo:1:002:4 0 4 > c787f580 1382724760 C Bo:1:002:4 0 2 > c787f480 1382725766 C Bi:1:002:3 0 4 = 23564552 c787f480 1382725832 S Bi:1:002:3 -115 32 < c787f400 1382726758 C Bi:1:002:3 0 32 = 0d0d0a4f 4b0d0a53 575f5645 5253494f 4e3a2053 54554946 43205631 2e302e30 c787f400 1382726807 S Bi:1:002:3 -115 32 < c787f380 1382727766 C Bi:1:002:3 0 2 = 0a20 : end of response c787f380 1382727819 S Bi:1:002:3 -115 32 < c787f500 1382728763 S Bo:1:002:4 -115 1 = 23 ; WHO SENDS THIS? c787f580 1382728804 S Bo:1:002:4 -115 1 = 56 c787f600 1382728814 S Bo:1:002:4 -115 1 = 45 c787f680 1382728824 S Bo:1:002:4 -115 1 = 52 c787f700 1382728839 S Bo:1:002:4 -115 2 = 0d0a c787f780 1382728869 S Bo:1:002:4 -115 2 = 0d0a c787f800 1382728886 S Bo:1:002:4 -115 2 = 0d0a c787f880 1382728899 S Bo:1:002:4 -115 1 = 4f ; from BluePro? c787f900 1382728909 S Bo:1:002:4 -115 1 = 4b c787f980 1382728919 S Bo:1:002:4 -115 2 = 0d0a c787fa00 1382728931 S Bo:1:002:4 -115 2 = 0d0a c787fa80 1382728944 S Bo:1:002:4 -115 1 = 53 ; this is a c787fb00 1382728953 S Bo:1:002:4 -115 1 = 57 ; SW Vers String c787fb80 1382728962 S Bo:1:002:4 -115 1 = 5f c787fc00 1382728972 S Bo:1:002:4 -115 1 = 56 c787fc80 1382728981 S Bo:1:002:4 -115 1 = 45 c787f500 1382729755 C Bo:1:002:4 0 1 > c787f580 1382729801 C Bo:1:002:4 0 1 > c787f300 1382729808 C Bi:1:002:3 0 1 = 23 c787f600 1382729870 C Bo:1:002:4 0 1 > c787f280 1382729875 C Bi:1:002:3 0 1 = 56 c787f680 1382729880 C Bo:1:002:4 0 1 > c787f300 1382729918 S Bi:1:002:3 -115 32 < c787f280 1382729938 S Bi:1:002:3 -115 32 < c787f200 1382730748 C Bi:1:002:3 0 1 = 45 c787f700 1382730770 C Bo:1:002:4 0 2 > c787f200 1382730818 S Bi:1:002:3 -115 32 < c787f180 1382731763 C Bi:1:002:3 0 1 = 52 c787f180 1382731812 S Bi:1:002:3 -115 32 < c787f100 1382732752 C Bi:1:002:3 0 32 = 0d0d0a4f 4b0d0a53 575f5645 5253494f 4e3a2053 54554946 43205631 2e302e30 ... The output from od -c repeats #VER and the response data over and over. But as I understand the above log the switching device just echos something the BluePro sends. And from the console I'm just sending a single line. Where does this data come from? BluePro runs 2.6.33, I tried to update to 2.6.36 but a commit between 2.6.33 and 2.6.34 results in a kernel panic. From git log I see that there were several changes in cdc-acm.c which deal with compatibility problems. So I'm looking for advice. Does the log above indicate a problem in the linux kernel on BluePro which could be fixed in later versions? In this case I would try to fix the panic and try later kernels. Or could I spare this time, blame the Atmel IP and try to find the reconnection issue? Best regards, Vitus -- Vitus Jensen, Hannover, Germany, Earth, Universe (current) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
