FTDI Connections Crash OHM on Startup

[GoogleCodeExporter]

What is the expected output? What do you see instead?

If two or more FTDI cables (usb to ttl) are connected to PC usb ports and OHM 
is not already running, then OHM will crash immidietly on startup of the 
application.

Notice two exceptions:
1. If OHM is already running, then connecting two or more FTDI cables will NOT 
crash OHM.

2.  If only a single FTDI cable is connected before running OHM, then OHM will 
NOT crash on startup.

To sum up, the crash only occurs when there are at least 2 FTDI cables 
connected to the PC usb ports prior to openning the OHM application.

Strange thing is that the crash report (see attached) seems to be talking about 
HDD's & ateempting to read/write protected data.

What version of the product are you using? On what operating system?

OHM Beta 0.6.0 on Windows 7 Professional (64-bit) (Service Pack 1)

Please provide any additional information below.

I've tried using different usb ports for the FTDI cables but the crash happens 
no matter what usb ports I'm using. It only seems to depend on the number of 
FTDI cables which are connected.

The said 2 FTDI cables are used to connect a couple of breadboard Arduino's to 
the PC, each of which is sending serial data over its dedicated COM port.

There are no T-balancers or other external hardware which is relevant to OHM 
are connected to the PC. 

Please attach a Report created with "File / Save Report...".

Original issue reported on code.google.com by joanna.b...@gmail.com on 25 Mar 2014 at 3:29

Attachments:

• OHM_FTDI_CRASH.png

[GoogleCodeExporter]

I have to admit I was skeptical on this bug, but this morning I've hit.
Same PC configuration as above (Win7 x64 sp1, OHM 0.6.0).

I had 2 FTDI cables and OHM didn't start until I've removed one of them. 
Virtual COM ports were inactive.
The crash popup appeared as soon as I removed one of the cables.

Original comment by drsur...@gmail.com on 13 Jun 2014 at 9:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The issue occurs when:
a) system is 64 bit Windows
b) There is more than one FTDI device where the info.Type is FT_DEVICE_232BM

This occurs during instantiation of a TBalancerGroup
There is a marshaling type mismatch for FT_HANDLE types defined in FTD2XX.cs. 
FT_HANDLE is defined as a structure containing private readonly uint handle;
uint handle is a 32 bit entity. A handle type on 64 bit platforms is a 64 bit 
entity.

When FT_OPEN() is called the 32 bit reference to handle is written with 64 bits 
which overwrites i defined in for (int i = 0; i < numDevices; i++) to 0. This 
causes an infinite loop where i < numDevices is always true (not to mention 
clobbering other things on the stack).

Changing 
  [StructLayout(LayoutKind.Sequential)]
  internal struct FT_HANDLE {
    private readonly uint handle;
  }
to
  [StructLayout(LayoutKind.Sequential)]
  internal struct FT_HANDLE {
    private readonly IntPtr handle;
  }
solves the problem as IntPtr is always guaranteed to be the proper size for the 
current platform.

Original comment by on.gw...@gmail.com on 12 Mar 2015 at 12:37