#1. Would it be "wise" to have an application program on the target processor that goes immediately into a do/loop without any debug statements running before the firmware upgrade process?
I don't believe that the nature of the user program is of any consequence. The firmware update process is similar to the download process. First, the ZX is put in a "command mode" by resetting it several times in quick succession. Once it is in the command mode, one of several commands is issued to the device, e.g. download, update, identify-self, etc. While in the command mode the user program is not being executed; the interpreter is not running at all.
#2. Pin 18 should flash at 4 hz "during" the firmware upgrade procedure. There should be a indication of the "emergency upgrade state" before the firmware upgrade takes place?
When the device is configured for emergency update, it does not execute the normal startup routine. Rather, it goes directly to a special mode awaiting the update data. This code is in the part of the AVR's Flash memory that is programmed during manufacturing and is never changed during firmware upgrades. That's why it should work even if a previous firmware update has failed or otherwise corrupted the field-modifiable portion of the Flash memory.
There is no external indication that the device is in the emergency update mode. Also, there is no "update in progress" indication. Since the device goes directly to update mode, i.e., there is no command to start the firmware update in the emergency mode, it was decided that it would be better not to toggle any I/O lines since there would be no way to suppress it. (In the normal firmware update mode you can suppress the I/O line toggling by -U option to zload.exe instead of the -u option.)
#3. The "standard EEprom" comes up (default) under the ZX firmware update window. Does this applies also to the ZX-40? or should I choose the alternate EEprom configuration. with the other option?
If you are using the "standard" EEPROM (an AT25256A or equivalent) you leave the EEPROM configuration set to "Standard EEPROM". You only need to change the setting if you are using an EEPROM with a page size other than 64 bytes or if the EEPROM does not support writing byte writes (i.e., it requires page writes). On the Firmware Update dialog, there is a Help button. Clicking this button should display an explanation of the options and when to select them.
#4. What would happen if the wrong EEprom is chosen during the firmware up-grade process?
The choice, correct or not, will not affect the firmware update process. The only effect of an incorrect choice will be that subsequent attempts to download user code may fail or attempts to modify Program Memory by the user program may fail because the VM might not interact correctly with the EEPROM. Even if the wrong choice is made, the EEPROM configuration can still be set to the correct settings using zload.exe or the "EEPROM Configuration" item on the Options menu.
#5. Unchecking the byte writeable does what to the EEprom configuration under firmware update?
During the firmware update, the system portion of Persistent Memory is re-written to the default values. After the firmware update is completed, the EEPROM configuration is sent to the device which stores it in Persistent Memory. When the VM begins running, it uses that configuration information to control how it interacts with the Program Memory EEPROM.
There should be a document revision to indicate every combination of checkbox and option selection of what EEprom goes with what checkbox/option/menu combination or selection?
You are correct that the descriptions of the various checkboxes, etc. are not in the manual. They are, however, available by clicking the Help button on the various dialogs.
