VM upgrade failure

[jm]

I have a Z24 chip, purchased last year. It worked fine until I tried the firmware upgrade to 2.3. Upgrading thru the IDE progressed for a while until a CRC error was repoted.

The chip became unresponsive. I tried the emergency upgrade but it failed with an ATN error. Finally I tried the emergency command line:
(I'm using a usb/com port 6)

zload -c6 -e zx24_2-3-0.zvm

"Device failed to timely acknowledge record 0.

Device reports bad signature, record 0.
Device reports bad signature, record 0.
Device reports bad signature, record 0.
Device reports bad signature, record 0.
Device reports bad signature, record 0.
Retry limit exceeded, aborting update."


The Zx24 has ovbiously suffered from a firmware lobotomy
How do I reload the chip?

[dkinzer]

It's difficult to speculate as to what might have gone awry. The most expedient solution for you is to send you a new ZX-24 which we will do today. We would like to get your current one back to try to determine what its problem might be.

If you want the replacement sent to a different address than your original order let me know soon.

[jm]

Thank you for your prompt reply.

Upgrading firmware acts like a pheromone for attracting Murphy and his laws

[mdown]

We have found that the GUI is very unreliable when it comes to upgrading VM in devices so we always use the zload.exe command.

-Mike

[victorf]

I have had the same problems as reported by JM. I too am connected to the Z24 via USB to a Elba USB to Serial converter, except mine is on PC COM2.

I have gone the IDE route initially and with the emergency upgrade. I attempted the command line version as a last resort with no luck.

Have I exhausted my options here or is there something else to try?

Any enlightenment will be appreciated.

Vic

[dkinzer]

[dlh]

USB->serial converters (and probably virtual serial ports used with network serial device servers) are quite a bit slower than a normal serial connection because a translation has to take place at both ends of the link. So, it might be that procedures expecting a response within some (short) set period might fail.

Also, not all such adapters are created equal. While almost all of the chipsets support all of the handshaking lines, some final designs handle them while others do not. Procedures which use DTR might work with some and not with others.