locked
FTDI devices and D2XX driver again... RRS feed

  • Question

  • Hi there!

    I'm using a Raspberry3 with OS IoT Core 15063 to drive about 20 DMX led pars. I use the DMX4All USB/DMX interface to connect the Raspi to the DMX bus. To access the USB/DMX interface (which utilizes a FT245R chip) I use the FTDI direct USB driver D2XX. Everthing is working fine.

    Ok, it is not - otherwise I would't post this message. Everthing is working fine for a while: 25 DMX-512 frames are sent per second for exactly 1800 seconds what is exactly 30 minutes. Then something kills my driver instance and stops my app. The UI keeps on the screen but is frozen. This happens in debugging mode (VS2015) as well as if the app is started on the Raspi. The FTDI driver is not time limited!

    My app is a headed one: I have to make it headed because the D2XX driver is not working in a background app. I've double- and triple checked my code: no overflow, no out of range, nothing. The DMX TX-thread is triggerd by a periodic ThreadPoolTimer and I'm sure there is no threading problem. I've got no clue whats going on...

    Suspend mode? While debugging?
    Power management problem - may be the Raspi powers down the USB Root hub?

    Has anyone an idea! Thanks!



    • Edited by Wobex Monday, May 22, 2017 9:38 PM
    Monday, May 22, 2017 9:32 PM

Answers

  • Hi Wobex,

    Have you been able to pin down the "something" part of your issue?

    Then something kills my driver instance and stops my app

    My suspicion is that your stall is the result of a wait that will never return.  Can you encapsulate that work into a subthread with a timeout so that you might pinpoint where you are waiting/blocking?

    Sincerely,

    IoTGirl

    • Marked as answer by Wobex Sunday, June 4, 2017 1:43 PM
    Friday, May 26, 2017 4:25 PM

All replies

  • Ok - must have been something in the D2XX driver but I don't know what.

    My workaround: I simply restart the driver every 25 minutes. Not very cool ...


    • Edited by Wobex Wednesday, May 24, 2017 2:34 PM
    Wednesday, May 24, 2017 2:33 PM
  • Hi Wobex,

    Have you been able to pin down the "something" part of your issue?

    Then something kills my driver instance and stops my app

    My suspicion is that your stall is the result of a wait that will never return.  Can you encapsulate that work into a subthread with a timeout so that you might pinpoint where you are waiting/blocking?

    Sincerely,

    IoTGirl

    • Marked as answer by Wobex Sunday, June 4, 2017 1:43 PM
    Friday, May 26, 2017 4:25 PM
  • Ok, your suspicion was right. The call

    n = await SomeIFTDevice.WriteAsync(some params)

    didn't return. New question now: why?

    The answer: I did miss to make this line threadsafe. This code is called every 25ms by a periodic ThreadPoolTimer, and it seems to happen that the code is executed by more then one thread. I'm sure that the thread duration is far less then 25ms - but who knows...

    After locking the thread's unsafe code using the following lines

    // Define a locker object
    static readonly object _locker = new object();
    
    
    // Lock critical code in the periodically executed DMX stream thread
    lock (_locker)
    {
       // stream DMX buffer to the DMX interface and wait until completed
       var t = SomeIFTDevice.WriteAsync(some params);
       while (t.Status!=Windows.Foundation.AsyncStatus.Completed);
       n = t.GetResults();
    } // unlock code
    
    
    
    everthing is fine. The thread of course now is synchronous (can't use await within locked code) but that's ok.

    Thank you for your hints, Wobex!



    • Edited by Wobex Sunday, June 4, 2017 2:09 PM
    Sunday, June 4, 2017 2:09 PM
  • You are very welcome! Great news that you found the cause as those are often tough to dig out.
    Sunday, June 4, 2017 2:17 PM