TraceEvents Win10 IOT ARM Device for GPIO Driver

Dear All,

I have some previous experience of USB UMDF driver and HID kernel mode driver on Windows7/Vista 4 years back. I clearly remember posting questions, reading others discussion, answering my level best etc. at this list that time.

As part of adhering to nature of work, slowly moved to device firmware, Windows SDK, application level and now back to drivers on Win8.1 Embedded Handheld, Win10 IOT. Target handheld device is ARM platform.

While working on some maintenance of scanner issue, I need to debug existing GPIO driver module. Came to know that in Win10 handhelds everything is restricted by Microsoft and it is not straight to debug driver like Win7, etc. For existing drivers I am using a tool called Field Medic.

In GPIO driver, I could see TraceEvent statements in almost all the driver functions. Please kindly provide a pointer to view those statement using any trace tool either on host machine or device itself. Thank you.

I’m guessing you mean the GPIO *CONTROLLER* driver? Not a GPIO *CLIENT* driver that uses a GPIO line(s) for data and/or a GPIO line(s) for interrupt(s)??

What problem do you need to debug in the GPIO controller? It should either work or not work, shouldn’t it?

Peter
OSR
@OSRDrivers

We are trying to view trace statements in GPIO client driver on the device
side with Win10 IOT on it. It uses interrupts to send key press event to
event store.

On Wed, May 16, 2018 at 1:30 AM, xxxxx@osr.com
wrote:

>


>
> I’m guessing you mean the GPIO CONTROLLER driver? Not a GPIO CLIENT
> driver that uses a GPIO line(s) for data and/or a GPIO line(s) for
> interrupt(s)??
>
> What problem do you need to debug in the GPIO controller? It should
> either work or not work, shouldn’t it?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

The CLIENT driver. Is this YOUR client driver?

I?m trying to figure out what you?re actual question is. Is it ?I have written a driver that I need to debug on a Windows Mobile platform?or is it something else?

Peter
@OSRDrivers

I have gathered information to my level best. Please review and suggest if any additional details are required. Thank you.

There is a hardware handle module which is piston gripped and has trigger to it. The handheld device sits on that module. When trigger is pressed on the handle, scanner gets activated on the device.

Update from person who worked on same handle but with handheld device running WEH6.5:

There are two GPIO pins are used to connect to handle and these two pins are the interrupt source to generate scan key event. Driver on the handheld will detect the handle. and set these two pins from UART mode to GPIO mode and handle has individual driver.

The driver on the handheld device will monitor the interrupts of these two pins and generate a key event to upper layer software.

So to isolate the root cause:

We need to confirm whether the driver reports scan key event. when we triggered then we will know the problem happens in driver layer or upper layer software

Handheld runs WIN10 IoT on it and is ARM based. Many restrictions from Microsoft on it. Cannot replace DLL, SYS files directly unlike other Windows platforms here. The driver code has trace events such as:

TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DRIVER, “Scan Button Driver %!FUNC! Entry”);

Exactly where they can be viewed. Simple file operations using fopen, zwCreateFile, Message Boxes are not serving the purpose here.

On Wed, May 23, 2018 at 5:40 AM, xxxxx@gmail.com
wrote:
> I have gathered information to my level best. Please review and suggest if any additional details are required. Thank you.
>
> There is a hardware handle module which is piston gripped and has trigger to it. The handheld device sits on that module. When trigger is pressed on the handle, scanner gets activated on the device.
>
> Update from person who worked on same handle but with handheld device running WEH6.5:
>
> There are two GPIO pins are used to connect to handle and these two pins are the interrupt source to generate scan key event. Driver on the handheld will detect the handle. and set these two pins from UART mode to GPIO mode and handle has individual driver.
>
> The driver on the handheld device will monitor the interrupts of these two pins and generate a key event to upper layer software.
>
> So to isolate the root cause:
>
> We need to confirm whether the driver reports scan key event. when we triggered then we will know the problem happens in driver layer or upper layer software
>
> Handheld runs WIN10 IoT on it and is ARM based. Many restrictions from Microsoft on it. Cannot replace DLL, SYS files directly unlike other Windows platforms here. The driver code has trace events such as:
>
> TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DRIVER, “Scan Button Driver %!FUNC! Entry”);
>
> Exactly where they can be viewed. Simple file operations using fopen, zwCreateFile, Message Boxes are not serving the purpose here.
>

That sounds extremely arbitrary. I was thinking of evaluating some new
NXP offerings with IoT, but if I don’t actually control the device
then there’s no point in me doing that.

For everyone who reads this, note that WHAT WE SAY HERE IS SPECIFIC TO WINDOWS IOT.

So, please confirm these things for me:

  • You’re using the standard in-box GPIO driver on Windows IOT.

  • You’re writing some sort of UWP application, in C# or something, that conceptually listens for the interrupt like described here:
    https:

    Is that all correct?

    In terms of debugging, you do it remotely, just like any other Windows system. You can hook-up WinDbg, for example.

    To Mr. R0b0t1:



I don’t know what you’re saying. There’s no reason you can’t control the device.

Peter
OSR
@OSRDrivers</https:>

On Wed, May 23, 2018 at 11:15 AM, xxxxx@osr.com wrote:
>
>
>
> For everyone who reads this, note that WHAT WE SAY HERE IS SPECIFIC TO WINDOWS IOT.
>
> So, please confirm these things for me:
>
> - You’re using the standard in-box GPIO driver on Windows IOT.
>
> - You’re writing some sort of UWP application, in C# or something, that conceptually listens for the interrupt like described here:
> https:
>
> Is that all correct?
>
> In terms of debugging, you do it remotely, just like any other Windows system. You can hook-up WinDbg, for example.
>
> To Mr. R0b0t1:
>
>


>
> I don’t know what you’re saying. There’s no reason you can’t control the device.

Well - I don’t want to derail the conversation - but it seems like
Microsoft has started to limit the customization potential of their
embedded OSes (which is technically just the desktop one, but not
really). In particular there seems to be no middle ground. I did read
the marketing material to find that UWP apps are the main focus. Fine,
I actually think a common focus will be a good thing for Microsoft’s
platform. But if I can’t push back the curtain there will inevitably
be problems.

Sure I control the device, some of the time, to the extent I get to
decide what code runs. But if I try to enable secure boot facilities
only to find I have to hack my way into the chain of trust I’m not
going to be very happy.

>
> Peter
> OSR
> @OSRDrivers
></https:>

Sure. But… you don’t.

Remember… this is an IoT device. You’re not going to ship your drivers on a DVD for your customers to install. You’re going to sell you DEVICE, pre-configured, will all your shit on it. You’ll build your own system image and then sign it. Even assuming you’re using IoT Core, there’s nothing that prevents you from doing this. See here:

https:</https:>

Don’t believe the gas. The “restrictions” are really no different to those we have on “desktop” Windows. Drivers need signed, and these days, you need an EV Cert. End of story, really.

Peter
OSR
@OSRDrivers