Serial USB - Unsigned Driver Fail

[johnsondav]

Hi Everyone

I am trying to venture into the realm of USB. I am using the following hardware:
- PIC18f4550
- EB006-30-9 Multi Programmer
- EB055-30-1 USB board (my design copied from Matrix)
- EB005-30-4 LCD Display (my design copied from Matrix)

The Flowcode program I am using is shown here:

USB Serial String Demo.fcfx

(13.87 KiB) Downloaded 332 times

I was not convinced that the one available for download was correct as the LCD display and USB components names were showing V5 in their titles. However, I have updated FC7 to latest - V7.2.1.4 Mar 31 2017.
I have also downloaded and installed the latest patch - Flowcode_7_Latest_200417 (Apr 20 2017)

The PIC18f4550 setting are shown here:

PIC18f4550 Conf settings.jpg (407.71 KiB) Viewed 15876 times

The program appears to run ok on the hardware with LCD displaying correctly when connected to the computer (Windows 10 Pro Build 1607)
OS Build 14393.1066

This is what my PC show when trying to communicate to the hardware connected. I am using the driver obtained from the project folder (Flowcode_USB_Serial_Driver) generated when compiled -

USB Install Fail.jpg (374.41 KiB) Viewed 15876 times

I am in no rush to get this working, but would need to include the USB feature in future designs.
Any advice would be very much appreciated as what I may be doing wrong or missed.

Kind Regards
Dave

[Benj]

Hi Dave,

If you've left the USB IDs as default then you can use the default USB Serial signed driver available here.
viewtopic.php?f=2&t=16552

To create your own USB product you will need to purchase your own unique USB IDs and a certificate and then you can sign the driver .inf file that Flowcode creates.

I've not signed any drivers for a while so am a bit rusty but can maybe dig out the details on how to do it if you need them.

[johnsondav]

Hi Benj

Thank You for quick replay. I have treid to update the driver to the one you have suggested, regretably, same problem.

Here is what Windows 10 displays:

Update Driver Software.jpg (221.57 KiB) Viewed 15868 times

I just don't know what the problem could be as to what is stopping it from starting! I am not that bothered about it being signed, I just would like to run.

Regards
Dave

[Benj]

This is my driver signing cheat sheet I created to help remember how it's done at a later date.

Hopefully it should help if you need to sign your own USB device drivers for use with Windows 8 and 10.

Driver Signing Instructions.docx

(18.43 KiB) Downloaded 407 times

The .inf file is the USB device driver, Flowcode will generate this for you but it is unsigned and modern Windows does not like this.

The .cat file is a protected, secure way of ensuring the .inf file is correct and has not been altered. The .cat file is what you create by doing the driver signing and is then unique to your specific .inf file.

[Benj]

I just don't know what the problem could be as to what is stopping it from starting! I am not that bothered about it being signed, I just would like to run.

Unfortunatley Windows 10 is bothered about if it's been signed or not. It won't work if not signed. If the IDs are default then you can use our signed driver. In Windows 7 you simply got a red box saying would you like to proceed, much easier for developers to play around and one of the many reasons I won't be moving to Windows 10 any time soon.


Looks like it could be a configuration problem. What crystal are you using on the EB006 board? I'm assuming you've replaced the 19.6608MHz crystal with a 20MHz crystal. I'm told the 19.6608MHz crystal does work but it's probably right on the edge of working and would recommend using the right value of crystal if available.

The Build -> Project Options should have a clock speed of 48000000 as your multiplying the 20MHz up to USB speeds using the PLL. This will only effect things like delays and other timing critical parts e.g. UART baud rates.

In the Configuration tab set the CPU SYS CLK Select to OSC/1, this is hopefully what's currently stopping it from working as you currently have it set to OSC/4.

The other config settings look ok.

[johnsondav]

Hi Benj

I have dug a little deeper and found this:

USB PnP Devices.jpg (201.22 KiB) Viewed 15864 times

So, not sure how to fix this one, I think its a 'Windows Device Policies' issue. I'll work on it over the next couple of days to see what I can find regarding 'PnP' USB communication. I'll keep you posted.

Regards
Dave

[Benj]

Hi Dave,

Did changing the configuration setting make no difference?

In the Configuration tab set the CPU SYS CLK Select to OSC/1, this is hopefully what's currently stopping it from working as you currently have it set to OSC/4.

[johnsondav]

Hi Benj

The crystal I had tried was 20Mhz. Adjusting to the setting you suggested using this crystal prevented the board from running, LCD displayed nothing. I have since tried various crystals ranging from 4Mhz upwards.Still with no success. I believe it to be associated with system polices regarding the installing of some drivers, or with PnP not allowing it to start. I am hoping to consult further as this is beyond my knowledge.

This trial and error approach produced other problems to Windows10, a list of 'com ports in use', which ment every time I tried a different set of crystal speeds, Windows incremented the com port upwards. Removing them proved difficult.

Still, I do feel the effort to get it working is worth while.

Regards
Dave

[johnsondav]

Hi Benj

I can now confirm what I had suspected, the problem is due to system policies for Windows 10 Pro 1607.
As of July 26 2016 changes were implemented, as I understand so far. Here is a quote:

Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal

The full article can be found here:
https://blogs.msdn.microsoft.com/window ... sion-1607/

Yes, I do have it working, but not without quite a lengthy workaround. I am working on a more permanent solution.

Here is working project:

Working Prototype

Serial_Com_Ver1.jpg (78.23 KiB) Viewed 15829 times

I'll keep you posted as I work towards a permanent solution.

Regards
Dave

[Benj]

Hi Dave,

Thanks for letting us know. This is very worrying going forward.

Last year, we announced that beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal) to be digitally signed by Microsoft. However, due to technical and ecosystem readiness issues, this was not enforced by Windows Code Integrity and remained only a policy statement.

Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change.

What a pain!

Your work around would be good to know.

[GTF]

Windows 10 does not request a driver for my 18F45K50 devices using the using the USB Serial component(V6), and I do not provide one to my customers.

[johnsondav]

Hi GTF

Please be aware this problem only relates to new instals of Windows 10 1607, not those which have arrived at this version through successive updates. Please read the above blog for a more detail explanation. Here is a quote:

Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal.

I do belive I have a permenant fix, but need to do some testing before I give any details. The drivers provided by Matrix are 'Signed', but are affected by the Windows 10 1607 policies of UEFI and secure boot of the computer hardware features (at least that is the case for my computer).

Hope to post details in the coming days.

Dave

[Benj]

We have looked at the new Windows 10 way of signing drivers and though it's annoying we now have something of a plan to upgrade all our drivers in the coming months.

Hopefully going via Microsoft will mean that Windows update will be able to find and install our drivers for you without having to manually download and install them. I won't hold my breath for this though.

Interesting that GTF says that the device is installed OK without a driver, or presumably using a compatible driver from Windows update.

[GTF]

I should have posted this image. I am using this with both Windows 10 Home and Pro(1607) versions.
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

Grant

[johnsondav]

Hi Grant

Not sure how you accomplish the use of a standard Windows USB driver for your PIC USB communication. I am sure others would like to know how you achieved that.

I have tried many times to get the driver working, but a Kernel driver that utilises PnP is forced to comply with UEFI policies, as of new build Windows 10 1607.

Dave

[GTF]

Hi Dave

Have you tried uninstalling the FC generated driver and allowing Windows to sort out the driver? I had the same issue with the FC driver: viewtopic.php?f=54&t=17371&hilit=+driver

TX buffer must also not exceed 8 bytes when I use this component.

[johnsondav]

Hi Grant
Yes, I have installed and uninstalled the driver. The problem was not the driver itself but the signature catalogue that ships with the driver. Windows just would not accept it. I have now resolved this issues. Everything is working correctly.

The problem caused by the signature catalogue not installing was - I could get the driver to load and the PIC would work. However, after unpluging the PIC and pluging it back in, it would not work, driver failed to run again.

Microsoft UEFI states - the driver was installed as 'developer mode'. So, how to make it permanent was my difficulty. Sorted now though. I'll by posting how I achieved this.

Another option suggested was to turn off secure boot and then install the driver. Once it is installed and working you will be able to turn secure boot back on and keep the driver in the protected driver environment - working.

Hope this clarifies what my difficulty has been.

Regards
Dave

[GTF]

Hi Grant

Not sure how you accomplish the use of a standard Windows USB driver for your PIC USB communication. I am sure others would like to know how you achieved that.

I have tried many times to get the driver working, but a Kernel driver that utilises PnP is forced to comply with UEFI policies, as of new build Windows 10 1607.

Dave

From the MSDN link

"If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the Device Descriptor. For more information, see USB communications device class (or USB CDC) Specification found on the USB DWG website. With this approach, you are not required to distribute INF files for your device because the system uses Usbser.inf."

Although I was not aware of this and did not alter the FC device descriptor. The FC Cal (usb_config_serial.c) specifies Class = 2 and Subclass = 0

I do understand the issue with the FC custom driver.

[johnsondav]

Hi Grant

What you have achieved looks brilliant. However, I am unable to locate the file (usb_config_serial.c). I have done a search over the entire hard drive, no such file exists. Therefore, I am unable to try what you have successfully achieve on your system.

I have had a look at some of the other files within FC7, and yes, the Descriptors for USB Class - are by default set to '00'. I do not feel comfortable to change these as this is beyond my skill level.

Still, good to know, your help and information is very much appreciated.

Many Thanks
Dave

[GTF]

It appears that these descriptors are in a new file in V7: usb_serial_descriptors.c

[johnsondav]

Hi Grant

Yes, these descriptors are in a different file in FC7, not sure which one, so reluctant to make any changes.

However, here is my workaround I used to get the USB signed drivers to install in a new clean build of Windows 10 1607 and 1703 build. All is working.

Installing USB FC7 Drivers.pdf

(599.43 KiB) Downloaded 336 times

Dave