Arduino Forum

Products => Arduino Due => Topic started by: dol86 on Oct 30, 2012, 12:34 pm

Title: Native port driver BSoD
Post by: dol86 on Oct 30, 2012, 12:34 pm
I'm trying to install the Arduino Due driver ("Arduino Due.inf" selected manually) but during the native port driver installation i get a blue screen ("bad_poll_caller"). The driver installation works only in windows safe mode but after the computer restart, and when i plug the arduino due, i get the blue screen. No sketch was uploaded on the board.
The programmable port works fine. I get the same blue screen on both my win7 computers.
Title: Re: Native port driver BSoD
Post by: mbanzi on Oct 30, 2012, 08:32 pm
can you provide us with as many details as possible? is is win7 64 or 32? what language ? english or something else.
any service pack o patch we should know of'

m
Title: Re: Native port driver BSoD
Post by: dol86 on Oct 31, 2012, 03:16 pm
Desktop
Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.120830-0333)
Language: Italian (Regional Setting: Italian)
BIOS: BIOS Date: 07/28/09 14:27:00 Ver: 08.00.15
Processor: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (8 CPUs), ~2.8GHz

Notebook
Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.120503-2030)
Language: Italian (Regional Setting: Italian)
System Manufacturer: Acer
System Model: Aspire 5750G
BIOS: InsydeH2O Version V1.11
Processor: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz (4 CPUs), ~2.3GHz

More info:
- i'm also using a duemilanove on both computers;
- nothing it's connected to the Due;
- i installed Visual Studio Express 12 for Desktop (with .NET framework 4.5), i don't think this is a useful information, but it's the "weirdest" thing i did in the last few days;
- i tested the Due on ubuntu 12.04 64bit (a partition of the notebook) and both usb ports work, but i had to upload a test sketch from windows because on ubuntu i can't compile any sketch, error message:
Code: [Select]
"Cannot run program ../hardware/tools/g++_arm_none_eabi/bin/arm-none-eabi-g++": error=2, File o directory non esistente
the file exist, i run the arduino ide as root, i did a chmod (777) for all arduino files.
- i'm not a lucky guy :D

IT: se preferisci, dato che l'inglese non è il mio forte, ti posso riscrivere tutto quello che ho fatto passo per passo in italiano :).
Title: Re: Native port driver BSoD
Post by: cmaglie on Nov 02, 2012, 01:49 pm
Hi dol86,

please, may you do the following check:

1) power the Due in any way (connect it from programming port for example, in order you didn't get any BsOD)
2) Press the erase button for 2 seconds (the little one just under the "COMMUNICATION" label)
3) Press the reset button
4) Try to plug the Due from the native port.

and let me know if you still get BsOD.

C
Title: Re: Native port driver BSoD
Post by: dol86 on Nov 02, 2012, 03:34 pm
Same results. When i plug the native port, windows finds the "Bossa Programming Port", then i tried to upload a simple sketch (open the serial port in setup(), print "Ciao" and a delay(1000) inside loop()) and the upload seems ok. At the end of the upload, in the Device Manager list, the Bossa Port was replaced by an "Arduino Due" device. I manually select the "Arduino Due" driver (from the drivers folder of arduino-1.5) and at the end of the driver installation i get the blue screen.
Am i doing something wrong during the installation process? Yesterday I did the same stuff on an other pc (windows vista 32bit italian) and it's works fine (both ports).
Title: Re: Native port driver BSoD
Post by: cmaglie on Nov 03, 2012, 07:42 pm
My test machine is a win7 64 ultimate with service pack 1. The driver here installs correctly.

You said that the driver installation works in windows safe mode.
I'm thinking: maybe you have another driver/software that conflict with the Due? Can you take a screenshot of the device manager in safe mode (with and without the Due plugged in) and the device manager after a normal reboot?

C
Title: Re: Native port driver BSoD
Post by: razer93 on Nov 06, 2012, 08:49 pm
my windows 7 32bit recognise only Arduino Due... never BOSSA ... how can i do?? is my arduino due fauly?
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 09, 2012, 09:11 am
Any resolution of the BSOD installing the Arduino Due native driver?

I also have a Windows 7 Pro SP1 64-bit, Dell XPS L702X i7-2670QM, 8GB RAM.  I get the BSOD after manually selecting the Arduino Due.inf driver.

The other BOSSA driver and Due Programming port installs without any issues.

Title: Re: Native port driver BSoD
Post by: DocOck on Nov 09, 2012, 10:26 pm
I am struggling with the same problem, pointing my Win 7 64bit Dell M6600 at the driver for my new Arduino Micro immediately bluescreens the computer with a BAD_POOL_CALLER error.  Blarg. 

Not sure if this is something being worked on, but I may just return the board to Radio Shack and call it a lesson learned. 
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 10, 2012, 02:17 am
I have a second laptop, with the same problem BSOD when installing the Arduino Due native port driver.
Windows 7 Pro SP1, 64-bit,  Sony Vaio FW590, Core2 Duo T9600 2.8 GHz, 6GB RAM.


Title: Re: Native port driver BSoD
Post by: 3dprinter on Nov 11, 2012, 04:30 pm
I'll add my vote(?) to this.

1: Installed the driver for the programming port. Worked "out of the box", ie. with updating the driver and pointing to the 1.5.1/driver library. Programmed the blink sketch. All OK.
2: Moved the cable to the native port. No driver was found/installed. Tried the fix in the other driver thread (http://arduino.cc/forum/index.php/topic,131100.msg987440.html#msg987440). It now started an install, but BSoD.
2b: After reboot, whenever the Due is plugged in with the Nativeport the machine BSoD (presumably trying to reinstall the driver)

Win7 Enterprise, 64bit, SP1 (intelCore i7, dual core M620)


Edit:Update:

Well, after 3 tries, it now no longer BSoD, but the driver does not create a COM port and is marked "not installed". Installing has no effect "The driver is installed and uptodate".
Title: Re: Native port driver BSoD
Post by: seppo on Nov 11, 2012, 08:05 pm
I seem to have the same behaviour as in the previous message :64 bit Windows 7 SP1 and processor Intel Core 2 Duo CPU P8700 2,53 GHz,
Arduino Due.inf driver causes BSoD.

and if before driver install , I press ERASE (communication erase button) the Native port is recognized as Bossa port ok and I can download sketch to
Due but after the download ends with CPU reset , new driver installation starts automatically and with Arduinodue.inf which causes then again BSoD.

My test code which downloaded when as Bossa port :
Code: [Select]

void setup() {
  // initialize serial communication at 1200 bits per second:
  Serial.begin(1200);
while (!Serial); 
}

// this input is just to cehck that serial comm works
void loop() {

  int input_data = REG_PIOC_PDSR;
  Serial.println(input_data);
  delay(1000);        // delay
}



tested also Native port driver installation in Windows XP SP2 machine and same behaviour as above ,

the Programming port works perfectly in both operating systems,

By the way: can Native port operate with higher speed than Prog port , where max. seems to be 115200 , with higher baud rates (230400 and 460800) starts giving errors,
I would like to operate with higher speed , therefore interested in Native port ,

BR,
Seppo
Title: Re: Native port driver BSoD
Post by: 3dprinter on Nov 11, 2012, 09:24 pm
That was interesting. Yes, it makes a difference if the ERASE button has been pushed or not. My last attempt left the win-pc hanging- not even mouse movement (hard power cycle required). OK, I'm done. Not using the native port until further notice.
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 12, 2012, 12:02 am
Yes, the ERASE button allows the SAM built-in bootloader to run as the BOSSA interface.  If you have a sketch loaded then the bootloader does not run.  The sketch runs as the Arduino Due USB interface.  Which also should be emulating the HID keyboard and mouse, but it doesn't seem to be working.

Also note that I have successfully installed the Arduino Due.inf driver under Windows XP (Home/Pro) SP3.  But the HID emulation still doesn't work.  However, the standard serialUSB interface works okay.


Title: Re: Native port driver BSoD
Post by: seppo on Nov 12, 2012, 10:06 am
With Arduino Due.inf Native port driver are you running the original .inf or have you made any changes to the driver content to make it work with
Windows XP SP3 ? I tried the changes suggested in earlier messages (like removing &MI00 and other suggestions ) with no luck,

but I'm sure somebody will find a solution to this driver question in near future, since quite many are reporting similar behaviour,

Seppo
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 14, 2012, 11:40 am
Okay, I have done a little more testing scenarios.  First on my Dell XPS Windows 7 SP1 64-bit, I found out the back USB ports are 3.0.  Only the side port is USB 2.0.  So previously I was only trying the back ports with my Due and Leonardo, both failed and got BSOD.

Now I tried multiple times the side USB 2.0 port and was able to get my Leonardo and Micro both to install the driver and work correctly with keyboard and mouse.  Unfortunately my Due still died BSOD during the driver install.  I think this could be because the HID emulation is not working correctly on the Due yet.  So it may not be handshaking correctly with the driver install.  (I say this because I have a couple of Windows XP SP3 32-bit systems that install the Due driver okay, and the SerialUSB works correctly, but the HID interface still never shows up.)

So for those of you with USB 3.0 ports, you may want to try it on USB 2.0 ports to see if it works any better, at least for the Leonardo and Micro.  It would interesting if someone else can get the Due on a USB 2.0 port.

Title: Re: Native port driver BSoD
Post by: Markus_L811 on Nov 14, 2012, 02:28 pm
Strange things goes on,

on my HP laptop all works Bossa, Programming Port, Arduino Due, (Windows 7 64bit SP1) on an DELL Optiplex works Bossa and Programming Port nothing else Arduinodue.inf not trieed any modification known from http://arduino.cc/forum/index.php/topic,131100.msg987440.html#msg987440 (http://arduino.cc/forum/index.php/topic,131100.msg987440.html#msg987440) nothing helps.

Markus
Title: Re: Native port driver BSoD
Post by: Markus_L811 on Nov 14, 2012, 10:18 pm
In my opinion maybe it's not an Arduino problem it looks more like an problem with Dell and there USB-Ports... could be wrong.
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 15, 2012, 03:35 am
My Sony Vaio Windows 7 SP1 64-bit, which has USB2.0 ports also gets BSOD when trying to install the ArduinoDue.inf drivers.  I don't think it is limited to Dell.

Has anyone got the Due native port working with HID Keyboard and Mouse emulation on any Windows platform or other platforms?

Title: Re: Native port driver BSoD
Post by: 3dprinter on Nov 15, 2012, 08:02 pm

e an problem with Dell and there USB-Ports... could be wrong.
Mine is a Thinkpad Lenovo. I cant seem to determine if it is 3.0 or 2.0 USB port
Title: Re: Native port driver BSoD
Post by: Louis Davis on Nov 15, 2012, 10:47 pm
I have found a problem in the Device Descriptor defined in the file USBCore.cpp

USB_DeviceDescriptorA has a device class of 2 if CDC is enabled and a device class of 0, if it is not.

The problem is the Device Descriptor for a Composite Device, needs to have a device class of 0 or Windows will not know it is a Composite Device.

I changed the code to use Device Class 0 in either case and recompiled a sketch.

After changing that, I see 3 devices show up when connected to the Native port.  I see a CDC device, a HID mouse, and HID Keyboard.

I haven't done any further testing to make sure they all work, but I don't get the BSOD anymore when installing the serial driver.

Code: [Select]
#ifdef CDC_ENABLED
#define DEVICE_CLASS 0x02
#else
#define DEVICE_CLASS 0x00
#endif

// DEVICE DESCRIPTOR
const DeviceDescriptor USB_DeviceDescriptor =
D_DEVICE(0x00,0x00,0x00,64,USB_VID,USB_PID,0x100,IMANUFACTURER,IPRODUCT,0,1);

const DeviceDescriptor USB_DeviceDescriptorA =
D_DEVICE(DEVICE_CLASS,0x00,0x00,64,USB_VID,USB_PID,0x100,IMANUFACTURER,IPRODUCT,0,1);

...

if (USB_DEVICE_DESCRIPTOR_TYPE == t)
{
TRACE_CORE(puts("=> USBD_SendDescriptor : USB_DEVICE_DESCRIPTOR_TYPE\r\n");)
if (setup.wLength >= 8)
{
_cdcComposite = 1;
}
desc_addr = _cdcComposite ?  (const uint8_t*)&USB_DeviceDescriptorA : (const uint8_t*)&USB_DeviceDescriptor;
        if( *desc_addr > setup.wLength ) {
            desc_length = setup.wLength;
        }
}
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 16, 2012, 01:33 am
Great!  I tried that change of the Descriptor to 0 in "\arduino-1.5.1r2\hardware\arduino\sam\cores\arduino\USB\USBCore.cpp" and tested the KeyboardAndMouseControl example sketch and it worked correctly.  (Note: I needed to delete the existing driver and let it reinstall to get the composite USB be recognized)

The question is, I double checked the "\arduino-1.0.2\hardware\arduino\cores\arduino\USBCore.cpp" file for the Leonardo and Micro, but they have the same class 2 definition if CDC_ENABLED?  So what is different here that makes it work?

Title: Re: Native port driver BSoD
Post by: hiduino on Nov 16, 2012, 05:33 am
I was able to confirm the Descriptor modification with my other two laptops.
Dell XPS Windows 7 SP1 64-bit and Sony Vaio FW590 Windows 7 SP1 64-bit both installed the ArduinoDue.inf driver correctly now for the Native USB port.  I also tested the KeyboardAndMouseController sketch and it works fine.

This modification is just a kludge at the moment.  We need to figure out the proper code fix for this issue.  Anyone else versed in USB stuff?


Title: Re: Native port driver BSoD
Post by: Louis Davis on Nov 16, 2012, 07:49 pm


The question is, I double checked the "\arduino-1.0.2\hardware\arduino\cores\arduino\USBCore.cpp" file for the Leonardo and Micro, but they have the same class 2 definition if CDC_ENABLED?  So what is different here that makes it work?



The reason is works on Leonardo is because of the following differences between Leonardo USBCore.cpp:
Code: [Select]
if (USB_DEVICE_DESCRIPTOR_TYPE == t)
{
if (setup.wLength == 8)
_cdcComposite = 1;
desc_addr = _cdcComposite ?  (const u8*)&USB_DeviceDescriptorA : (const u8*)&USB_DeviceDescriptor;
}


and Due USBCore.cpp:
Code: [Select]
if (USB_DEVICE_DESCRIPTOR_TYPE == t)
{
TRACE_CORE(puts("=> USBD_SendDescriptor : USB_DEVICE_DESCRIPTOR_TYPE\r\n");)
if (setup.wLength >= 8)
{
_cdcComposite = 1;
}
desc_addr = _cdcComposite ?  (const uint8_t*)&USB_DeviceDescriptorA : (const uint8_t*)&USB_DeviceDescriptor;
                if( *desc_addr > setup.wLength ) {
                    desc_length = setup.wLength;
                }
}


When I captured a USB protocol trace on my system, setup.wLength was 18 for the Get_Descriptor request.

Therefore, on Leonardo, setup.wLength will not equal 8 and _cdcComposite will not get set to 1. So the function will return USB_DeviceDescriptor, which has the Device Class set to 0.

On Due, setup.wLength will be greater than or equal to 8 and _cdcComposite will get set to 1. So the function will return USB_DeviceDescriptorA , which has the Device Class set to 2.

If the Arduino only wanted to expose a CDC interface, then a Device Descriptor with a Device Class of 2 is correct.
If the Arduino is exposing more than one interface, then it should only return a Device Descriptor with a Device Class of 0. This indicates that each interface will specify its own class information and operate independently.
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 17, 2012, 03:12 am
Great!  Thanks for the explanation.  That is very helpful in understanding what is going on.

The question is what intent is Arduino meant for this option?  I would think everyone will have problems with this out of the factory.

Is setting the Class to 0 the correct action?  Or changing the comparison to match the avr code?  Or something else?


Title: Re: Native port driver BSoD
Post by: Stan09 on Nov 17, 2012, 07:50 am
I am having the same issue on WinXP;
so should I change
Code: [Select]
#ifdef CDC_ENABLED
#define DEVICE_CLASS 0x02
#else
#define DEVICE_CLASS 0x00
#endif


to

Code: [Select]
#ifdef CDC_ENABLED
#define DEVICE_CLASS 0x00
#else
#define DEVICE_CLASS 0x00
#endif


in arduino-1.5.1r2\hardware\arduino\sam\cores\arduino\USB\USBCore.cpp?
Title: Re: Native port driver BSoD
Post by: hiduino on Nov 17, 2012, 10:53 am
Yes, that would be the quick fix.  That worked for me on various Windows (XP/7 32/64-bit) machines.
I am not sure what the long term fix will be.

Title: Re: Native port driver BSoD
Post by: cmaglie on Nov 18, 2012, 11:40 pm

I have found a problem in the Device Descriptor defined in the file USBCore.cpp

USB_DeviceDescriptorA has a device class of 2 if CDC is enabled and a device class of 0, if it is not.

The problem is the Device Descriptor for a Composite Device, needs to have a device class of 0 or Windows will not know it is a Composite Device.

I changed the code to use Device Class 0 in either case and recompiled a sketch.

After changing that, I see 3 devices show up when connected to the Native port.  I see a CDC device, a HID mouse, and HID Keyboard.


answered also here:
https://github.com/arduino/Arduino/commit/3e9ef444018f64f2eee76909a602dfb440d87ee5#commitcomment-2169570


Louis,

first thank you, I've seen the forum thread, great work.

This commit was due to the behaviour seen on older macosx (<=10.6.8 ).

We got the following facts:

    macosx versions <= 10.6.8 sends a wLenght of 0x12
    if we keep the == condition (==0x08) the CDC-Serial is not seen from macosx
    changing the condition to >= 0x08 make it working

Note that this happens only with high-speed devices. If you attach a low-speed device macosx
requests a wLength of 0x08. This probably makes Leonardo unaffected.

I'm going to set the condition back to ==, but my question now is: there is a workaround to make it
working also on macos 10.6.8 and older?
Title: Re: Native port driver BSoD
Post by: Louis Davis on Nov 19, 2012, 06:36 pm
I am not sure why there is a need for conditional code to send a different Device Descriptor depending on the length of the request.

If I understand the USB specs properly, the device should return the same Device Descriptor, no matter what the length is requested.

The USB code looks like it is trying to handle three scenarios:
1. CDC only
2. HID only
3. Composite: CDC and HID

If the USB code is configured as CDC only, CDC_ENABLED defined and HID_ENABLED not defined, then it should have a Device Descriptor with Device Class of 2.
If the USB code is configured as HID only, CDC_ENABLED not defined and HID_ENABLED defined, then it should have a Device Descriptor with Device Class of 0.
If the USB code is configured as Composite, CDC_ENABLED defined and HID_ENABLED defined, then it should have a Device Descriptor with Device Class of 0.

I believe that you could simplify the code and accomplish this behavior by making the following changes to the code:
1. Change the preprocessor macro to set Device Class to 0 if HID is defined, this covers the HID only and Composite cases. Otherwise, set Device Class to 2, this covers the CDC only case.
2. Eliminate the alternate USB_DeviceDescriptor.
3. Remove the conditional code based on request length.

Code: [Select]
#ifdef HID_ENABLED
#define DEVICE_CLASS 0x00
#else
#define DEVICE_CLASS 0x02
#endif

// DEVICE DESCRIPTOR
const DeviceDescriptor USB_DeviceDescriptor =
D_DEVICE(DEVICE_CLASS,0x00,0x00,64,USB_VID,USB_PID,0x100,IMANUFACTURER,IPRODUCT,0,1);

...

if (USB_DEVICE_DESCRIPTOR_TYPE == t)
{
TRACE_CORE(puts("=> USBD_SendDescriptor : USB_DEVICE_DESCRIPTOR_TYPE\r\n");)

desc_addr = (const uint8_t*)&USB_DeviceDescriptor;
                if( *desc_addr > setup.wLength ) {
                    desc_length = setup.wLength;
                }
}


I haven't fully tested this, but I think this will accomplish what is desired.
Title: Re: Native port driver BSoD
Post by: Markus_L811 on Nov 20, 2012, 09:33 am
The question is why does it work on the most Windows Systems but not on all? What are the differences? There musst something that explains that.
Title: Re: Native port driver BSoD
Post by: cmaglie on Nov 24, 2012, 11:22 am

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:
https://github.com/arduino/Arduino/commit/70351fc34150b1288079996839082e751b176821

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?
Title: Re: Native port driver BSoD
Post by: Louis Davis on Nov 24, 2012, 08:00 pm
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.
Title: Re: Native port driver BSoD
Post by: bitron on Nov 27, 2012, 09:19 pm
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!
Title: Re: Native port driver BSoD
Post by: Louis Davis on Nov 28, 2012, 09:40 pm
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:

http://lists.apple.com/archives/usb/2010/May/msg00007.html
http://lists.apple.com/archives/usb/2010/May/msg00009.html

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.

Thoughts?
Title: Re: Native port driver BSoD
Post by: bitron on Nov 28, 2012, 11:20 pm
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:

1)
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.

2)
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.

3)
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.
Title: Re: Native port driver BSoD
Post by: bitron on Nov 29, 2012, 07:39 pm
After some more investigation on this issue, these two messages caught my attention:

  http://lists.apple.com/archives/usb/2010/Nov/msg00040.html
  http://lists.apple.com/archives/usb/2010/Nov/msg00041.html

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.
Title: Re: Native port driver BSoD
Post by: pjrc on Dec 02, 2012, 10:17 pm
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"....

http://lists.apple.com/archives/usb/2010/Nov/msg00040.html

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.
Title: Re: Native port driver BSoD
Post by: f.schiano on Apr 08, 2014, 12:09 pm
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,
Fabrizio.
Title: Re: Native port driver BSoD
Post by: f.schiano on Apr 08, 2014, 12:18 pm
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,
Fabrizio.