Reboot Causes Loss of Communication (Error -16)

The Acroloop products have a specified protocol for initialization over the PC bus, that being a CR (0x0D). (this is similar to the serial port protocol, which requires 2 CR characters, separated by at least 50 ms, to establish the incoming baud rate) When a card is rebooted from its command line or reset via the hardware switch, the protocol *requires* that the first character seen is a CR. The communications channel does not process incoming characters until a CR is received.

AcroView, like other host applications, makes use of the Fast Status subsystem. For the ISA products, this is a feature of the driver. Periodically, the driver sends binary inquiries down to the card and caches the results for expedient delivery to a host app.

When a card is rebooted or reset while the Fast Status system is active, it is virtually guaranteed that the communications protocol will be broken. The fact that the card will sometimes communicate is purely a matter of luck. The first 0x0D seen by the card may well be in the middle of an incoming binary frame, causing a loss of synchronization.

It is impossible for the driver to determine that a card has been reset or rebooted. In fact, no part of the API can determine this condition. Therefore, it is impossible to guard against an unexpected reboot or reset. A host application could provide for a "safe" reboot, but still could not guard against an unexpected hardware reset.