Nios2-terminal uses the wrong COM port

Windows has two names for devices like COM ports. The familiar names like COM1, COM2, COMn can be passed to higher level Windows API functions such as CreateFile. The less familiar names like \Device\Serial0, \Device\Serial1, \Device\Serialm… can be passed to lower level Windows API functions such as NtCreateFile. Windows maps the two names together and for any given machine this mapping is noted in the registry database under the key \HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM.

Is it common for port COM<n> to be mapped to \Device\Serial<n-1> but this is not always the case. For example we have a number of computers where COM1 is a normal serial port and COM3 is an Intel Active Management Technology Serial over LAN port. On these machines COM1 is mapped to \Device\Serial1 and COM3 is mapped to \Device\Serial0.

We would normally use the command “nios2-terminal –uart –port=/dev/com1” to test our board. This was working fine with Quartus II version 7.2. After upgrading to Quartus II version 9.0 it no longer works and we have to use the command “nios2-terminal –uart –port=/dev/com2”. This makes no sense as the computer has no port COM2.

Quartus II 7.2 shipped with a cygwin1.dll whose APIVersion is 1.60. With that version the sequence of events is as follows:

We issue command “nios2-terminal –uart –port=/dev/com1”.

Nios2-terminal.exe calls cygwin1.dll function _open64 to open /dev/com1.

Cygwin1.dll calls kernel32.dll function CreateFile to open \\.\com1.

Kernel32.dll calls ntdll.dll function NTCreateFile to open \??\com1.

This is all good.

Quartus II 9.0 shipped with a cygwin1.dll whose APIVersion is 1.68. With that version the sequence of events is as follows:

We issue command “nios2-terminal –uart –port=/dev/com1”.

Nios2-terminal.exe calls cygwin1.dll function _open64 to open /dev/com1.

Cygwin1.dll calls ntdll.dll function NTCreateFile directly to open \Device\Serial0.

This is not good at all as our board is now connected to the Intel AMT SOL COM3 port and not COM1 as it should be.

The later version of the cygwin1.dll is clearly making the unjustified assumption that COM<n> is mapped to \Device\Serial<n-1>. If we issue the command “nios2-terminal –uart –port=/dev/com8” then cygwin1.dll calls NTCreateFile to open (mythical) \Device\Serial7. The cygwin developers need to remove this assumption and use the registry device mapping or go back to calling the higher level CreateFile API.