Conditions:
ZBasic IDE Version: 1.1 / ZBasic Compiler version 1.2 / ZX-40 Firmware 1.16 <-- cannot upgrade / ZLoad v1.1.3 ???
I tried to upgrade my firmware with the IDE and with the command line prompt. In both cases my ZX-40 will not upgrade.
Error: Device failed to timely ack record 1 - command prompt/IDE
New software upgrade IDE 1.1 Compiler 1.2
-
- Posts: 193
- Joined: 25 January 2006, 19:56 PM
Try the emergency update procedure. This has to be done using zload.exe and you need to add two jumper wires. See the instructions in the manual.
- Don Kinzer
-
- Posts: 193
- Joined: 25 January 2006, 19:56 PM
firmware upgrade problems zx-40
I tried the emergency update and I get the error
"Unexpected device response 0x0d, record 1."
It alternates with the same error (between repeated resets)
"Device failed to timely ack record 1"
"Unexpected device response 0x0d, record 1."
It alternates with the same error (between repeated resets)
"Device failed to timely ack record 1"
-
- Posts: 193
- Joined: 25 January 2006, 19:56 PM
Firmware update
Upgrade questions:
The application program I had in the ZX-40 contained a long "boot-up sequence" with debug statements being generated during the restart process.
#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?
The emergency upgrade procedure is to ground pins 5 & 7 on the target e.g. ZX-40. Pin 21 should be low and pin 18 should flash at a 4 hz rate "during" the update process.
#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?
Note: I had a buzzer to indicate the reset before the program went into the infinite do/loop.
I have the standard 256A EEprom on the ZX-40.
#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?
#4. What would happen if the wrong EEprom is chosen during the firmware up-grade process?
#5. Unchecking the byte writeable does what to the EEprom configuration under firmware update?
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?
The application program I had in the ZX-40 contained a long "boot-up sequence" with debug statements being generated during the restart process.
#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?
The emergency upgrade procedure is to ground pins 5 & 7 on the target e.g. ZX-40. Pin 21 should be low and pin 18 should flash at a 4 hz rate "during" the update process.
#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?
Note: I had a buzzer to indicate the reset before the program went into the infinite do/loop.
I have the standard 256A EEprom on the ZX-40.
#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?
#4. What would happen if the wrong EEprom is chosen during the firmware up-grade process?
#5. Unchecking the byte writeable does what to the EEprom configuration under firmware update?
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?
#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.
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.#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?
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.)
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.#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?
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.#4. What would happen if the wrong EEprom is chosen during the firmware up-grade process?
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.#5. Unchecking the byte writeable does what to the EEprom configuration under firmware update?
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.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?
- Don Kinzer
-
- Posts: 193
- Joined: 25 January 2006, 19:56 PM
New software upgrade IDE 1.1 Compiler 1.2
Re-downloaded firmware on the new replacement
ZX-40(s) and everything seems OK
ZX-40(s) and everything seems OK