View previous topic :: View next topic |
Author |
Message |
GregEigsti
Joined: 12 Jan 2008 Posts: 12
|
CCS USB CDC and Mac OS X (Leopard) failure... |
Posted: Thu Jan 29, 2009 3:45 pm |
|
|
I got my IR app working nicely and ported my Win32 code over to the Mac; but she don't work.
On the Mac the 18F2550 device shows up as a cdc device (cu.usbmodemXXXX and tty.usbmodemXXXX) and I can successfully send bytes to it as evidenced by flashing LEDs... However I never receive anything back from the device (e.g. ACK). I know the 18F2550 hardware/project is good (works from a Win32 box with my code - bootloader and app control) and feel pretty confident that my Mac code is ok. I am having the same problem with the pyserial module as well - I can send bytes but never receive my ACK.
I have tried using both the cu.usbmodemXXXX and tty.usbmodemXXXX devices (one at a time) and guess that maybe I'll try using both at the same time (one for read, one for write) but I am doubtful that this will make a difference. Either device cu/tty shows the same symptom - can write from the Mac but not receive.
I have also taken a look at PIC CDC com code off of the web and my code seems pretty compliant with what I have seen.
If there is anyone out there who has gone down this road I'd be ecstatic to hear from you! It feels like there is a bit of Mac magic that I am missing...
Additionally - after a little more experimenting. I moved the 18F2550 device back to the Win32 PC and it works there. Also reflashed the CCS USB bootloader just to be sure...
After bringing the project back to the Mac I noticed that I can send a byte once (but not RX). In order to be able to send again I need to unplug/re-plug the project to reset the CDC serial port on the Mac (I guess). I grabbed some data from the Apple Console that looks like:
I get this when plugging the device into USB:
1/29/09 2:01:37 PM kernel AppleUSBCDCACMData: start: InterfaceMappings dictionary not found for this device. Assume CDC Device...
1/29/09 2:01:37 PM kernel AppleUSBCDC::createSerialStream NON WAN CDC Device
1/29/09 2:01:37 PM kernel AppleUSBCDC::createSerialStream using default naming and suffix...
1/29/09 2:01:37 PM kernel AppleUSBCDCACMData: Version number - 3.2.12, Input buffers 8, Output buffers 16
1/29/09 2:01:37 PM kernel AppleUSBCDCACMData: Version number - 3.2.12, Input buffers 8, Output buffers 16
I get this when "communicating" with the device:
1/29/09 2:01:52 PM kernel USBF: 29640.326 AppleUSBUHCI[0x4417000]::Found a transaction which hasn't moved in 5 seconds on bus 0x1a, timing out! (Addr: 3, EP: 0)
Thanks!
Greg |
|
![](templates/subSilver/images/spacer.gif) |
GregEigsti
Joined: 12 Jan 2008 Posts: 12
|
|
Posted: Fri Jan 30, 2009 12:22 am |
|
|
[update - d'oh, too tired and have been looking at this too long. Read the Apple list quote incorrectly, I beleive that the bmCapabilities check has been relaxed in later versions of the OS, not tightened up. Oh well].
I have been looking at this for a couple of days and not making much headway; but tonight I think I stumbled upon something. The gist is that in later versions of Mac OS they have tightened up their USB driver support so that your device must be closer to the true USB/CDC spec in order for it to work. This post outlines the problem that another user is having and someone answers (Apple Tech?) who points out the non compliance of their device. Interestingly their problem is kind of like mine - more interesting is that the PIC/CCS/CDC device has the same non-compliance issue described below.
What follows is a snippet from the aforementioned thread.
Quote: | The reason the ACM Control driver is failing is the Call Management Functional Descriptor indicates the device does not support call management (bmCapabilites = 0x00) and in version 3.1.9 of the CDC driver this is a failure case for the ACM Control driver.
Comm Class Call Management Functional Descriptor
Raw Descriptor (hex) 0000: 05 24 01 00 01
This check has been relaxed but it's in version 3.2.9 (and later) of the CDC driver which is available on 10.5.5 (I think - certainly 10.5.6) and later.
In order to fix this, for 10.4.11, you will need to make the bmCapabilites field of the Call Management Functional Descriptor either 0x02 or 0x03 (preferable). |
Here is what the PIC/CCS/CDC data looks like:
Comm Class Call Management Functional Descriptor
Raw Descriptor (hex) 0000: 05 24 01 00 01
I wonder if they are using PIC/CCS/CDC in their device?
From what I can tell the "bmCapabilites field" is set in usb_desc_cdc.h around line 97 - though I cannot say for sure...
Can anyone comment on the meaning of this value and what might happen if I change it myself?
Has CCS provided an update to the CDC stuff that brings it more in line with the USB spec? Or is this a PIC issue?
I'll continue to research but wanted to mention this as it seems significant.
Thanks!
Greg |
|
![](templates/subSilver/images/spacer.gif) |
GregEigsti
Joined: 12 Jan 2008 Posts: 12
|
|
Posted: Fri Jan 30, 2009 11:33 am |
|
|
A new batch of part arrived yesterday so I will embark on another planned project which I want to connect to a Mac. This time I will start with the HID example and verify Mac connectivity from the beginning. |
|
![](templates/subSilver/images/spacer.gif) |
GregEigsti
Joined: 12 Jan 2008 Posts: 12
|
HID Works! |
Posted: Sat Jan 31, 2009 12:39 am |
|
|
I built up that new project today (home sick) and have been playing with HID since then. I am able to communicate with the 18F2550 as a HID device (TX and RX). HID is not as dirt easy as CDC but I am just thankful to be able to communicate with the device from the Mac.
Now what to do... continue working on the device that I started today or refactor the IR project from CDC to HID?
I have found that I can send buffers of at least 33 bytes back and forth to the HID device (32 bytes data + 1 byte count of data bytes). Is it foolish to use a report of this size? The project started today will deal with buffers of 64 bytes (controlling an 8x8 RGB LED array via SPI) and the IR project deals with data sets in the ~200 byte range.
Glad I wrote that HID code on the Mac a few years back. Always nice to recycle!
Thanks!
Greg |
|
![](templates/subSilver/images/spacer.gif) |
ChristianE Guest
|
It doesn't work for me.... |
Posted: Tue Apr 28, 2009 3:31 pm |
|
|
Hi,
I am having the same errors but with a HID device we cribbed from the CCS examples.
Were you able or willing to get the CDC version working?
I only have these errors on the latest macbook and macbook pros from Apple, not on our older iMacs.
4/28/09 4:32:28 PM kernel USBF: 95779.508 AppleUSBEHCI[0x4003800]::Found a transaction past the completion deadline on bus 0x24, timing out! (Addr: 2, EP: 0)
TIA,
Christian |
|
![](templates/subSilver/images/spacer.gif) |
Tre42 Guest
|
Similiar Issues |
Posted: Wed Apr 29, 2009 11:15 am |
|
|
I had similar issues in the past with Mac's and even some specific Windows 64 bit drivers. I think that there is a problem in the descriptors as you seem to also confirm.
I never figured it out and still don't support Mac OS X as a result.
Very interested to see if anyone makes any headway. I don't have a Mac so testing is a bit difficult for me. |
|
![](templates/subSilver/images/spacer.gif) |
|