CCS USB CDC and Mac OS X (Leopard) failure...

[GregEigsti]

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

[GregEigsti]

[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.

[GregEigsti]

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.

[GregEigsti]

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

[ChristianE]

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

[Tre42]

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.