Discovered why CARDREAD.EXE is not communicating with Arduino

 LED ON PIN 13 FLASHES BUT I DON'T USE THAT PORT

I noticed that when I fire up the CARDREAD.EXE program which is unable to communicate, I see the LED light on the Arduino, the one that is controlled by pin 13. I am not making use of that pin and thus nothing should cause it to light, go off, and then flash periodically, but that is what happens.

Using a terminal emulator or the serial monitor does not trigger this behavior, it is unique to the failing connection from the older Windows based application. 

IT APPEARS THAT BOOTLOADER INTERACTION IS BEING TRIGGERED

I did some quick searching online and found that the bootloader on the Arduino manipulates pin 13 in this pattern. On a first connection to upload code, the loader waits for a second (the long LED interval I see), then subsequent fast resets (triggered by DTR sent over the link) are much faster before they decide that code is NOT being uploaded.

This implies that something in the older program and Windows is causing DTR to pulse downward on each open of the port, then the code sends the 10 tries of the R character and gives up apparently before the boot loader has abandoned its control of the link. 

POTENTIAL FIXES

The bootloaders required the reset button to be pressed on an Arduino in the earlier days, but this was 'enhanced' to use DTR as a reset such that the button did not need to be touched anymore. There are ways I can modify or block the bootloader so that the Arduino does not do its reset, allowing me to test this theory. 

There are two separate but related actions taking place, one is desirable but the other causes my problems. The practice of Windows in dropping DTR during the opening of a COM port triggers the auto reset of the Arduino; this is useful and I want to preserve it. When the Arduino resets, the boot loader takes control of the serial link to look for code being uploaded from the IDE, taking a second to wait for code to arrive; this is the behavior that causes me problems.

The Windows code sends a control sequence to the port to set special characters, but they are all zero valued instead of the proper codes for things like XON and end of transmission. It think this is the root cause of my problem, because that sequence seems to cause the Arduino bootloader to wait for code to begin streaming. That wait is long enough that the CARDREAD.EXE program drops the port and starts over.

If I can block the bootloader from taking control, it should all work well. I would still get the reset when the COM port is opened. The only function I would lose is that the normal way of uploaded code to the Arduino would not work. If I have a tenable workaround to upload sketches and a way to block the bootloader otherwise, I can overcome this problem. 

It seems the best method is to upload my sketch without any bootloader. This will cause it to run immediately after it resets and ignore any sequences that would trigger the loader wait. To this end, the IDE allows you to save the compiled sketch, which is stored both with and without the bootloader. 

I then will have to upload it via a programmer. I decided to use another Arduino as the programmer for now, but might look into my programmer devices at the shop and switch over. These all access the ICSP header on the board to update the flash memory with my sketch.