Not finding device in Headless Mode. Any ideas?

[ghost]

Hi Jark,

Sample works fine. When I modify the Sample "Blinky Headless" to use the drivers, the device is not found. Headless has no .exe and is run as a service: http://ms-iot.github.io/content/en-US/win10/HeadlessMode.htm

The project type is "Library" and output type is a Windows Runtime Component. My query to ftManager.GetDeviceList(); always returns 0 devices no matter how often (and when) I call it. The driver is still installed fine while running in headless (I checked from PShell)...

Any ideas? Is there a way to set the device explicitly or troubleshoot to find out where the problem is?

Have you tried Headless Mode?

Thanks!

[djaus2]

I would suggest that running it as a service is the problem. Try building and running the exact same code, as far as is possible, as an .exe And see if the problem remains. If so then the query probably needs to be elevated to a higher level. Let us know the outcome as I could follow up on that for you. I suspect there are limitations in Win 10 IoT Core as to what a service can do.

[djaus2]

Or it could be that there is some UI code in the driver ??

[Jark]

Hi,

The most likely suspect is that this file: https://github.com/Jark/FTDISample/blob/master/src/FTDISample/Package.appxmanifest in your project doesn't contain the same DeviceCapabilit y section. The ftdi driver only recognizes the usb devices defined there.

I haven't verified it works for headless but I don't see why it wouldn't work. Might do some testing next week, but have no time right now to look at it.

Let me know how you get on.

[ghost]

Hi Guys, I suspected the Package.appxmanifest too at first, but all the DeviceCapability code is there. So I resorted to the assumptions that djaus2 also voices above. I need headless for something due by Wed., but since I can't figure out why it is not working,I'll have to resort to a minimal headed for the moment and eagerly await Jark's conclusive results. Thanks for the prompt reply. Impressed.

See also: http://stackoverflow.com/questions/32932263/windows-iot-core-headless-mode-usb-serial-device-no-longer-visible

[djaus2]

Just done a folder comparison btw Headless Blinky and Jark’s project.

The main config difference is in Package Manifest.

But if you have copied across that then OK.

I’ll give it a go tomorrow (Australian Time) .. merge the FTDI sample with Headless Blinky (or just a new Headless IoT project) and see where I get. If you want to make a version of your project available I could look at that as well.

Cheers

David Jones

Embedded MVP (Just been renewed)

Sportronics

Australia

http://embedded101.com/Blogs/David-Jones http://embedded101.com/Blogs/David-Jones

Windows 10 Developer Resources: http://embedded101.com/Blogs/David-Jones/entryid/674/Windows-10-Resources http://embedded101.com/Blogs/David-Jones/entryid/674/Windows-10-Resources

From: hubert-associates [mailto:notifications@github.com] Sent: Sunday, 4 October 2015 8:09 PM To: Jark/FTDISample FTDISample@noreply.github.com Cc: David Jones davidjones@sportronics.com.au Subject: Re: [FTDISample] Not finding device in Headless Mode. Any ideas? (#4)

Hi Guys, I suspected the Package.appxmanifest too at first, but all the DeviceCapability code is there. So I resorted to the assumptions that djaus2's also voices above. I need headless for something due by Wed., but since I can't figure out why it is not working,I'll have to resort to a minimal headed for the moment and eagerly await Jark's conclusive results. Thanks for the prompt reply. Impressed.

— Reply to this email directly or view it on GitHub https://github.com/Jark/FTDISample/issues/4#issuecomment-145329329 . https://github.com/notifications/beacon/AL9NEXksDy1dVtU1DnXDFVjBX6DFtFU-ks5o4ORAgaJpZM4GIg24.gif

[ghost]

Thanks, yes, Package.appxmanifest DeviceCapabilities is equivalent everywhere in my versions but there are a few appxmanifest differences as noted in my Stackexchange link above ... and the significant difference that it is component lib and not an exe. As soon as I create an .exe (i.e. headed) it works again fine. I'm now working around with a "blind headed" version to make progress :-) My sources no problem but I'll need to get them online...

... and if one looks at the generated AppxManifest.xml in the headless bin directory, there is a UWPShim.exe that appears to activate all the components. Looks like they are all there?

 <Extensions>
<Extension Category="windows.activatableClass.inProcessServer">
  <InProcessServer>
    <Path>UWPShim.exe</Path>
    <ActivatableClass ActivatableClassId="RpiHeadlessCS.Models.HxaAppSettings" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="RpiHeadlessCS.Devices.DeviceNode" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="RpiHeadlessCS.StartupTask" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.USB.BulkRequest" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.USB.ControlRequest" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.FTManager" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT2232H_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT232R_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT2232D_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT232H_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT232AM_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FTXSeries_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT4232H_EEPROM" ThreadingModel="both" />
    <ActivatableClass ActivatableClassId="FTDI.D2xx.WinRT.Device.EEPROM.FT232BM_EEPROM" ThreadingModel="both" />
  </InProcessServer>
</Extension>

[djaus2]

What if you run the lib on a headed device?

From: hubert-associates [mailto:notifications@github.com] Sent: Monday, 5 October 2015 12:48 AM To: Jark/FTDISample FTDISample@noreply.github.com Cc: David Jones davidjones@sportronics.com.au Subject: Re: [FTDISample] Not finding device in Headless Mode. Any ideas? (#4)

Thanks, yes, Package.appxmanifest DeviceCapabilities is equivalent everywhere in my versions but there are a few appxmanifest differences as noted in my Stackexchange link above ... and the significant difference that it is component lib and not an exe. As soon as I create an .exe (i.e. headed) it works again fine. I'm now working around with a "blind headed" version to make progress :-) My sources no problem but I'll need to get them online...

— Reply to this email directly or view it on GitHub https://github.com/Jark/FTDISample/issues/4#issuecomment-145351461 . https://github.com/notifications/beacon/AL9NEdGlKMZmiXQ1rWsbxWFV9YHdxORhks5o4SV_gaJpZM4GIg24.gif

[djaus2]

I've blogged on this and created a simplified version of the app on GitHub with a UW App project and Windows Runtime Startup Task project that both use the same code to access FTDI. Yes there is a problem with the Startup Task use of the D2XX driver: (http://embedded101.com/Blogs/David-Jones/entryid/695/Win-10-IoT-Core-FTDI-Serial-Driver-Headless-Startup-Task-problem)

[Jark]

From reading your blog post, looks like it might use the message loop under the hood (https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows), which is not started when you run a headless application.

In the past it was possible to start the message loop yourself if you need to run something as a a windows service that calls a dll that requires it, but I'm quite new to Windows RT so I have no idea if it's possible.

Any chance of posting the full stack trace?

[djaus2]

I've added it as link from my blog (towards bottom of page). The direct link is: http://embedded101.com/Blogs/David-Jones/entryid/696/win-10-iot-core-ftdisimpleiot-debug-trace-for-startuptask There are two debug traces. One with Managed Code and one with Native. Mixed is not supported. I've added a few comments at the bottom of that link.

[djaus2]

I've raised this issue in a couple of places. Here is the information I have provided:

The FTDI driver only works with Headed apps.

Recently I have been involved in an activity to use the FDTI D2XX RT Surface (ARM) Driver on Windows 10 IoT Core Raspberry PI. My Blog has links to all of this activity: http://embedded101.com/Blogs/David-Jones/entryid/695/Win-10-IoT-Core-FTDI-Serial-Driver-Headless-Startup-Task-problem I suggested the use of that driver and Zark (https://github.com/Jark/FTDISample ) implemented a comprehensive Universal Windows (10) app that uses it. He also documented how to install the driver. I further documented on my embedded101.com blog it and recently developed and published a cut down app and Startup Task projects: https://github.com/djaus2/FTDISimpleIoT

There were a lot of calls for the FTDI driver on this platform. Microsoft currently does not have a solution.

Recently a user has highlighted an issue, as per the content of the above blog. There is an issue with the driver when running in headless mode, where a Startup Task is used instead of the UW app. In summary:

• Instantiation of the FTManager is errant: o It gets instantiated (it’s not null and has properties) o But the driver reports an error after instantiation returns.
• As we don’t have the driver code or .pdb for the driver we can’t debug the issue
• ??It has been suggested that the driver might be making a call to the Windows message loop which isn’t started with the Startup Task ??
• A Managed Code try-catch does not capture the error.
• No FTDI devices get listed by the manager whereas for the same code on a UW app all of this works.

There is a significant audience for this driver. My original blog on this has had 1300+ views: http://embedded101.com/Blogs/David-Jones/entryid/666/win-10-iot-core-ftdi-serial-driver

[tomkuijsten]

I think this can be closed as with the IoT build the FTDI devices are supported natively.

[Jark]

Yeah, agree that we can close this for now. Although it would be nice to support the FTDI driver natively in headless mode if more performance is required or if more features are needed.

[ghost]

Ok, so still not supported in HeadLESS? What the? :-)

[tomkuijsten]

Yes it does, just tried it and works fine.

[ghost]

Thanks. OK, will try it out...

[ghost]

Thanks. Just tested. The device is recognized in headless mode by IoT-Core. Anybody have a starter example of using the device similar to the WinRT one above? I use the WinRT-version successfully but an not sure what to replace with the "standard" device driver and what to leave in...

Else, looks like this one may be the best starter: https://ms-iot.github.io/content/en-US/win10/samples/SerialSample.htm

[tomkuijsten]

The following snippets are ripped from my source. It won't compile with just copy/paste, but shouldn't be too hard to fix.

To get the serialdevices:

var selector = SerialDevice.GetDeviceSelector();
var allSerialDevices = await DeviceInformation.FindAllAsync(selector);

foreach(var itemId in allSerialDevices)
{
   var serialDevice = await SerialDevice.FromIdAsync(itemId);
   // dosomething with it
}

To read data from the device

private async void StartReadingData()
{
    Debug.WriteLine("START reading from serial adapter");

    try
    {
                // _adapter is the SerialDevice
        if (_adapter != null)
        {
            _adapterReader = new DataReader(_adapter.InputStream);
            // Set InputStreamOptions to complete the asynchronous read operation when one or more bytes is available
            _adapterReader.InputStreamOptions = InputStreamOptions.Partial;

            // keep reading the serial input
            while (!_cancelTokenSource.IsCancellationRequested)
            {
                await ReadAsync();
            }
        }
    }
    catch (Exception ex)
    {
    }
    finally
    {
        Debug.WriteLine("STOP reading from serial adapter");
    }
}

private async Task ReadAsync()
{
    try
    {
        uint ReadBufferLength = 1024;

        // If task cancellation was requested, comply
        _cancelTokenSource.Token.ThrowIfCancellationRequested();

        // Create a task object to wait for data on the serialPort.InputStream
        var bytesRead = await _adapterReader.LoadAsync(ReadBufferLength).AsTask(_cancelTokenSource.Token);

        if (bytesRead > 0)
        {
            var data = _adapterReader.ReadBuffer(bytesRead);
            // do something with the data
        }
    }
    catch (Exception ex)
    {
        Debug.WriteLine($"Read error: {ex.Message}");
    }
}

To write some bytes

public async Task WriteBytes(byte[] bytesToWrite)
{
    if (_cancelTokenSource.IsCancellationRequested)
    {
        return;
    }

    try
    {
        var nrBytesToWrite = bytesToWrite.Length;
        var bytesWritten = await _adapter.OutputStream.WriteAsync(bytesToWrite.AsBuffer());
    }
    catch (Exception ex)
    {
    }
}

[ghost]

Hey, thanks a million. I did get it in fact working for me yesterday but a comparison with yours can definitely help improve mine!