USB HID Bootloader not working with Windows 10 OS

[Rotary_Ed]

Like a number of others, have found that when switching to MS Windows 10 OS that the USB_HID bootloader app no longer functions. I have tried numerous approaches found on-line and in the forum to fix the problem, but alas none have worked.

I even tried substituting certified VID and PID in the USB_HID source code, compiling it and programming the chip thinking that perhaps Windows 10 required a certified VID and PID. But that also did not solve the problem.

I first installed the Mikro USB18F Drivers package, but that too made no difference and I must admit I am not sure that the drivers are required for USB_HID to function. However, while working on this approach I found something that may have bearing on the problem - if , indeed, the drivers are required for USB_HID app.

Seven layers down I found an apparent problem with the USB18F installation app. While the OS never reported any problem while I attempt to install the drivers, apparently the installation app does not exectue on Windows 10. See attached image ("DPInst does not run with Windows 10"). I found this 7 layers of hidden folders deep.
C:\users\computer\appdata\local\Temp\IXP000.Tmp\DPInst.exe.

DPInst being the executable that is there to install the drivers. It appears not to function according to the message with my Windows 10 OS. and therefore presumably never installs the drivers.

Could this be the problem with USB_HID bootloader on Windows 10. Its interesting that Windows 10 appears to detects when the PIC32MX795F512L .bootload firmware is active as I immediately get a message "USB device not recognized by Windows 10. See attached image "USB not Recognized"

I have a world wide product that I use USB-HID to load firmware updates to and so resolving this problem is important to me. Any assistance would be greatly appreciated.

Thanks

[Rotary_Ed]

Looks like my previous post about DPInst.exe not running was not the problem with the USB_HID bootloader app. I
manage to get Windows 10 into Test Mode where I ran the DPInst.app successfully. So apparently it is not recognized by MS windows 10 as a "signed" app, but in the test mode the Driver checker is disabled permitting you to load and "Unsigned" driver. This time DPInst.exe did execute. However, unfortunately that did not solve my problem with USB_HID.

Sorry for the false lead.

[Rotary_Ed]

I found the answer in the mikrobootloader manual. "Bootloader uses USB HID Class connection, and NO additional OS drivers are required for proper operation."

So that appears to indicate that the USB18F drivers are NOT required for the USB_HID bootloader app.

Makes me wonder if something has changed with the way Windows treats the USB HID Class of devices.

[VCC]

Hi,
if, for some reason, you have an old bootloader code, it might still use wrong delays to implement the timeout when waiting for connection. See this: viewtopic.php?f=172&t=61455
I was able to successfully compile an old bootloader, using the corrections above and also the corrections specified in: viewtopic.php?f=164&t=66186&start=30#p265908 and viewtopic.php?f=164&t=66186&start=30#p265963 for PIC32MX270F256D and mikroPascal v4.0.0. The USB HID Bootloader (v2.1.0.0) detects the device and successfully loads the firmware (a simple LED blink) on both Windows 8.1 and Windows 10.
I didn't test the bootloader, which comes with mikroPascal v4.0.0. It has the required corrections when implementing the timeout. However, the P32MX270F256D.mpas definition file, still has the wrong value for the _BOOT_FLASH_SIZE constant.

[Rotary_Ed]

Thanks a million, VCC!!!

That did the trick. All the suggestions that it was a problem with Windows 10 OS turn out to be wrong.
Increasing the time out value in the bootloader firmware source code did the trick.

I loaded the recompiled bootloader code on my board and then hooked it up to my Windows 10 machine
and the USB HID bootloader recognized my board and connected. Have not yet tried to load code through it as the rest of
my software development system is still on my Windows 7 machine, but I'm sure it will now work.

Greatly appreciate you sharing the fix.

[VCC]

Hi,
it's not increasing the overall timeout, it's decreasing the delays between iterations, i.e. replacing the

Code: Select all

Delay_10ms();
Delay_10ms();

with a smaller delay, or close to 0 altogether. That 20ms delay is what Win10 does not like.

[Rotary_Ed]

Ok, Thanks VCC

Yes, I see where in their latest code Mikro has reduced it from
the Two 10msec delays to one 1msec delay. Sorry, my mistake, thought it was the timer delay.

Code: Select all

   end;
      Delay_1ms();
      if timer = 0 then // Do we have a timeout?
        begin
          Result := 0;  //   Yes, return with do application code.
          Exit;
        end;