Using (DR)STRACE to compare Windows program execution

Question

I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.

I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:

• NodeJS and v4.x of the library [works]
• NodeJS and v6.x of the library [fails]
• Python and PySerial equivalent [works]

Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).

Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.

I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.

Update 2017 Nov 10

I reached out to FTDI support asking:

I use the FT231X in many of my products. I need some help with understanding how the Windows FTDI driver manages power. More to the point, I'm hoping you can help me understand how to direct the driver to allow the full 500mA allowed by USB to be delivered to my product by a Windows computer.

The reply was:

Just use our FT_Prog utility to set the max VBUS current to 500 mA:

This drive current becomes available after the FT231X enumerates.

I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.

Answer 1

Here is an alternative theory you could look into:

Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.

Answer 2

I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.

i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor

Power Management in Serial Port Drivers (Windows CE 5.0)

Windows CE 5.0 Send Feedback The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port. Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.

Source: https://msdn.microsoft.com/en-us/library/aa447559.aspx

about changes from serialport v4 => 6

• new Stream Interface
• but nothing changed with the core opening method of the port.
• also nothing changed in the bindings which open the port
• node serialport is a collection of bindings written in c++