Go Down

Topic: Native port driver BSoD (Read 22276 times) previous topic - next topic


I haven't fully tested this, but I think this will accomplish what is desired.

I did some tests, replacing back the if condition to wLentgth==8, and with the full patch provided by Louis David,
here the results:

OSwLength==8    LD patch
Win 7 ultimate (64)OKOK
Linux Ubuntu 11.04 (32)    OKOK
MacOS 10.7.2OKOK
MacOS 10.6.8No Serial PortNo Serial Port

With my Windows box I didn't experienced the BSoD, so probably both patches solves it as already reported in this thread.

For now I stick to what Leonardo do:

can you check if the latest ide-1.5.x solves the BSoD?

I'd like to apply the patch of Louis David, but I don't remember why the condition (with the duplicated descriptor) was introduced, I should clear that before.

Besides that, the question now is: what's the matter with macosx 10.6.8? Has anyone access to such SO and can explain what's happening?

Louis Davis

I have attached the Due USB descriptor information captured from USB Prober on OS X 10.8.2.

It would be interesting to compare this information captured on 10.6.8

It would probably be helpful to have the captures from a failing case and a successful case on 10.6.8 to compare.


Hi, you can find attached a couple of files generated by USB Prober on a Mac OS X 10.6.8, one for each behaviour (the names should be self-explanatory).

The "NoSerial" one is generated when on the Due is running a sketch (just a "SerialUSB.begin(115200);" and nothing else) uploaded with the IDE built from the fabc658a942de659d44f22f196701d04b857f094 commit.

The "SerialOK" one is generated uploading the same sketch with the same IDE, but after restoring the ">=8 patch" so that the serial port appears.

I hope this helps!

Louis Davis

The only difference in the USB Prober captures is the Device Class in the Device Descriptor.

I did some more research and found some interesting posts to the Apple developers lists about a very similar issue:


It's not exactly clear which version of OS X is being discussed, but it is probably < 10.6.8.

The posts seem to indicate there were limitations in the way OS X handled USB composite devices with CDC in older versions of OS X.

Based on this info, I don't think it would be worth the effort to try and pursue a solution that would work for all current versions of OS and also 10.6.8.



Nov 28, 2012, 11:20 pm Last Edit: Nov 28, 2012, 11:30 pm by bitron Reason: 1
I'm afraid that this is the most significant evidence that confirms the hypothesis that Paul Stoffregen made during the test phase of the Due: we are facing a Snow Leopard bug in the CDC driver implementation that has been fixed in Lion only.

At this point, these are my thoughts:

Quick and dirty (temporary) solution: provide a way to implicitly set the device class code at runtime, when needed.  In this case the workaround could be activated from within the sketch, from example reading the logic level on an input pin.

Trace the USB communication between the Mac and the Due and look for some kind of *fingerprint* that can tell us when the host is a Mac OS 10.6.8: this seems unlikely, but why not to try.

Provided that this could be a solution, develop a USB driver for the Due, but, as Louis Davis pointed out, this is hardly worth the effort...

I'll do some test on 2) within the next weekend and let you know.


Nov 29, 2012, 07:39 pm Last Edit: Nov 29, 2012, 07:41 pm by bitron Reason: 1
After some more investigation on this issue, these two messages caught my attention:


Given that:

  A) the USB probe output reported in the first message is related to a full speed USB device implementation;

  B) at the date of the second message the latest released version of Mac OS X was 10.6.4; version 10.6.5 was released 5 days later (http://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard);

  C) during the test phase of the Due no issue was experienced when the Due was still configured as a full speed device (I'll check this again in the next days, just to be shure...).  Only when the high speed configuration is enabled the serial port is not detected (as cmaglie already pointed out);

this is my educated guess: is it *possible* that something has been fixed in 10.6.8?

In the second message Paul Stoffregen says that (only) mouse and disk appear on OS X (he doesn't mention the CDC-ACM Serial that is detected on Windows and Linux), but we experienced a different behaviour (as described in C) ).

Provided that the device configuration of Paul Stoffregen's demo is different (Miscellaneous/Common Class device), is it possible that a similar configuration can solve the problem?  Of course this should be considered only a workaround, but, in my opinion, a better one compared to the 1) mentioned in my previous post.


For years, I and many others tried to convince Apple to add composite device support to their CDC driver.

In November 2010, I finally got through to the right people at Apple.  They agreed, but said they didn't have any standards compliant devices for testing.  I quickly made a test device based on a Teensy 2.0 and custom code.  I tested it carefully on Windows and Linux, and ran it with the USB-IF command verifier tool.  I shipped it to Cupertino and hoped for the best.

In early 2011, I emailed their developer.  Apparently he fixed the driver in a matter of days, but Apple has a lengthy approval process for releasing new code.  You can see a message from late 2010 where they mentioned my device and its descriptors as "will be supported on the Mac in the fairly near future"....


The "fairly near future" turned out to be 10.7 (Lion) released in the summer of 2011.

My understanding is 10.6.x has the old driver, which simply does not support CDC as part of a composite device.

However, if you *really* want to make this work on 10.6.x, many years ago I did discover a terrible hack that makes it work on Apple's old driver.  It violates the USB standards and it not recognized by the Windows driver (at least the XP SP3 driver and Vista pre-SP1 driver), but the Linux driver is able to figure things out and use the device.  Publishing code that does not work with Windows is not very practical.... but if anyone really wants that code, just email me directly, paul at pjrc dot com.


So guys, my Arduino DUE at some point is not recognized anymore if connected through Native Port. I am working with Windows 7 64bit.

I have another Arduino DUE and if I connect it through the native port it works.

What should I do?

Thanks for the help,


It is recognized again doing this procedure:

1- Press the erase button for 2-3 sec
2-Press the reset button for 8 seconds

I donĀ“t know why, but now It works.

I hope this will help someone,

Go Up