Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

TraceEvents Win10 IOT ARM Device for GPIO Driver

OSR_Community_UserOSR_Community_User Posts: 110,218
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.

Comments

  • Peter_ViscarolaPeter_Viscarola Posts: 6,649
    <quote>
    While working on some maintenance of scanner issue, I need to debug existing
    GPIO driver module
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Posts: 110,218
    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:

    >
    > While working on some maintenance of scanner issue, I need to debug
    > existing
    > GPIO driver module
    >
    >
    > 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: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Peter_ViscarolaPeter_Viscarola Posts: 6,649
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Posts: 110,218
    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.
  • R0b0t1R0b0t1 Posts: 128
    On Wed, May 23, 2018 at 5:40 AM, xxxxx@gmail.com
    <xxxxx@lists.osr.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.
  • Peter_ViscarolaPeter_Viscarola Posts: 6,649
    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://github.com/Microsoft/Windows-iotcore-samples/tree/develop/Samples/PushButton/CS>;

    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:

    <quote>
    if I don't actually control the device
    then there's no point in me doing that.
    </quote>

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

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • R0b0t1R0b0t1 Posts: 128
    On Wed, May 23, 2018 at 11:15 AM, xxxxx@osr.com <xxxxx@lists.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://github.com/Microsoft/Windows-iotcore-samples/tree/develop/Samples/PushButton/CS>;
    >
    > 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:
    >
    > <quote>
    > if I don't actually control the device
    > then there's no point in me doing that.
    > </quote>
    >
    > 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
    >
  • Peter_ViscarolaPeter_Viscarola Posts: 6,649
    <quote>
    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.
    </quote>

    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://docs.microsoft.com/en-us/windows-hardware/manufacture/iot/>;

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!