Native port driver BSoD

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

my windows 7 32bit recognise only Arduino Due... never BOSSA ... how can i do?? is my arduino due fauly?

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.

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.

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.

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

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 :

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

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.

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.

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

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.

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 Navie USB port drivers (Arduino Due mode) - #5 by hiduino - Arduino Due - Arduino Forum nothing helps.

Markus

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.

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?

Markus_L811:
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

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.

#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;
        }
	}

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?

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?

hiduino:
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:

	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:

	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.

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?