Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 9  
15 May 18 05:28
Uday Bhaskar
xxxxxx@gmail.com
Join Date: 15 May 2018
Posts To This List: 3
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.
  Message 2 of 9  
15 May 18 16:00
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6264
List Moderator
TraceEvents Win10 IOT ARM Device for GPIO Driver

<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
  Message 3 of 9  
17 May 18 00:36
Uday Bhaskar
xxxxxx@gmail.com
Join Date: 15 May 2018
Posts To This List: 3
TraceEvents Win10 IOT ARM Device for GPIO Driver

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 <xxxxx@lists.osr.com> wrote: > <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)?? > <...excess quoted lines suppressed...> --
  Message 4 of 9  
17 May 18 15:44
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6264
List Moderator
TraceEvents Win10 IOT ARM Device for GPIO Driver

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
  Message 5 of 9  
23 May 18 06:40
Uday Bhaskar
xxxxxx@gmail.com
Join Date: 15 May 2018
Posts To This List: 3
TraceEvents Win10 IOT ARM Device for GPIO Driver

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.
  Message 6 of 9  
23 May 18 08:07
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 127
TraceEvents Win10 IOT ARM Device for GPIO Driver

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. > <...excess quoted lines suppressed...> 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.
  Message 7 of 9  
23 May 18 12:16
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6264
List Moderator
TraceEvents Win10 IOT ARM Device for GPIO Driver

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/PushBu tton/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
  Message 8 of 9  
23 May 18 14:44
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 127
TraceEvents Win10 IOT ARM Device for GPIO Driver

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: <...excess quoted lines suppressed...> 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 >
  Message 9 of 9  
23 May 18 17:25
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6264
List Moderator
TraceEvents Win10 IOT ARM Device for GPIO Driver

<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
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 23:47.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license