PCI-485/4, WinXP, Paradigm debugger hangs?

[JohnCourtney]

We have been using the Paradigm debugger (http://www.devtools.com/pcpp/debugger.htm) with a National Instruments PCI-485/4 4-port RS-485/422 card instead of a regular COM port. The host PC was an OmniTech Pentium 2, 400 MHz, running Windows NT 4. We started using this N.I. card years ago because the UART on our target hardware is RS-422 instead of RS-232 and we could not find an adequate 232-to-422 converter. (Adequate = supports 115 Kbps and RTS/CTS flow control)

Our internal IT folks have been "encouraging" us to replace WinNT with WinXP. We are doing that by replacing the PC's instead of upgrading Windows. The replacement PC's are hand-me-downs from elsewhere in the company. They are Dell Pentium 3's, approx. 1 GHz, running WinXP with Service Pack 2.

We moved one of the N.I. cards into one of the XP PC's. Now we cannot use the Paradigm debugger. When I try to perform the debugger's communication test, the debugger reports that it opened the COM port, then it hangs. I have seen the same problem with two different XP PC's and two different N.I. cards. I have tried versions 1.8, 1.6, and 1.5 of the NI-Serial software. All show the same problem.

I am able to access the ports on this N.I. card with the Procomm PLUS terminal emulator. When I enter pairs of NUL characters (control-@), I get the expected responses from the Paradigm debugger monitor, PDREMOTE/ROM, on the target.

I am also able to use the ports on this N.I. card to connect a Wind River Tornado target server to a different target (different processor) that is running VxWorks instead of PDREMOTE/ROM.

We recently found an adequate 232-to-422 converter that can be used with a standard PC COM port. It is the B&B Electronics 422CEC.

http://www.bb-elec.com/product_family.asp?FamilyId=18&TrailType=Sub&Trail=11, not the 422LCOR or 422CFCR.

When I connect this converter to a regular COM port on the XP PC and the target's UART, the Paradigm debugger communicates with the target with no problem.

Does it mean anything in particular that the Paradigm debugger hangs, as described above, when I specify to use one of the ports on the N.I. card? Does it suggest a particular Windows API call that the debugger is calling to transmit data?

[Robert M]

Have you tried using another utility, such as Portmon, to isolate what call is causing the Paradigm debugger to crash?  If you can identify what command is causing the problem we may be able to help.  What does Paradigm have to say about the issue?

Thanks,

[JohnCourtney]

Paradigm recommended installing their latest hotfix since it had a change regarding serial port handling. I did so but the problem still happened.

I had thought about using "portmon" from sysinternals over the weekend. I did so this morning. The data logged by "portmon" at the time that the Paradigm debugger hung were:

7944  09:52:46  PCW.EXE  IOCTL_SERIAL_GET_COMMSTATUS  NISerP011 

7944  09:52:46  SUCCESS 

7945  09:52:46  PCW.EXE  IRP_MJ_WRITE  NISerP011  Length 1: 00

7945  09:52:46  CANCELLED 

7946  09:53:38  PCW.EXE  IRP_MJ_CLEANUP  NISerP011 

7946  09:53:38  SUCCESS 

7947  09:53:38  PCW.EXE  IRP_MJ_CLOSE  NISerP011 

7947  09:53:38  SUCCESS

Unfortunately the timestamp on the "CANCELLED" entry does not reflect the actual time interval between my instructing the debugger to connect to the target, my clicking the debugger's "Cancel" button (which had no effect), and my terminating the debugger from the Windows task bar.

In contrast, the equivalent region of data logged by "portmon" for the successful case were:

7760  10:36:41  PCW.EXE  IOCTL_SERIAL_GET_COMMSTATUS  Serial0

7760  10:36:41  SUCCESS

7761  10:36:41  PCW.EXE  IRP_MJ_WRITE  Serial0  Length 1: 00

7761  10:36:41  SUCCESS

7762  10:36:41  PCW.EXE  IOCTL_SERIAL_GET_COMMSTATUS  Serial0

7762  10:36:41  SUCCESS

I have omitted the remaining logged data for the successful case.