Flaky ZX44a

Discussion specific to the DIP and TQFP packaged ZX devices like the ZX-40, ZX-44, ZX-32 and ZX-328 series. The differences between these devices is primarily the packaging and pinout so most issues will apply to all devices.
Post Reply
mdown
Posts: 62
Joined: 03 February 2006, 5:46 AM
Location: Dallas, Texas
Contact:

Flaky ZX44a

Post by mdown »

I have a single production board, out of 50 that has a flaky ZX44a. Initially I was able to download firmware just fine, and in fact an older version of the firmware is still running on it. However when I try and download new firmware I get "No download ack from device." from zload.

The device also resets fine so ATN seems to be working, but it won't ident. I tried to download the VM and got "Unexpected device response - 0x00, record 0." from zload as well. I haven't tried the emergency download yet, I will have to solder a few test points together.

One thing to note, we are using in conjunction with the ZX, and have been on several boards the SiLabs CP2101 usb adapter. These are part of the board and interface directly to the ZX uart pins.
mdown
Posts: 62
Joined: 03 February 2006, 5:46 AM
Location: Dallas, Texas
Contact:

Post by mdown »

A newly discovered symptom: If you send any character through the debug port the device resets.
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Re: Flaky ZX44a

Post by dkinzer »

mdown wrote:when I try and download new firmware I get "No download ack from device." from zload.
The symptoms that you describe suggest that the device is not receiving serial characters correctly.

A download begins with toggling ATN several times in quick succession to get the device into "command mode". If the device responds with the correct acknowledgement character, the downloader assumes that it is in command mode, ready to receive commands. (Success this far indicates that the device's serial transmission is working fine.) If the correct acknowledgement is not received, an error is reported that the device did not respond to the ATN signal. The possible causes for this failure include: no power to the device, no main clock to the device, serial transmission is not working correctly, or a faulty device.

Once in command mode, a download is initiated by sending it a download command over the serial port. If the device accepts the command and goes into download mode it sends back an acknowledgement character. If the downloader fails to receive this character it reports that the device did not respond to the download command. Otherwise, it proceeds with sending download records to the device, each of which is acknowledged affirmatively or negatively.

Since I suspect that the device's serial reception is not working, I would suggest setting up a test program that sends a stream of U characters (ASCII code &H55) and looking at pin 9 of the ZX-44 with an oscilloscope. You should see a clean square wave on that pin with a frequency equal to half of the baud rate of the character stream.
- Don Kinzer
mdown
Posts: 62
Joined: 03 February 2006, 5:46 AM
Location: Dallas, Texas
Contact:

Post by mdown »

Don the weird thing is that my program outputs the debug.print statements fine. Otherwise I could understand why that would be a problem.
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

mdown wrote:the weird thing is that my program outputs the debug.print statements fine.
I'm suggesting that the transmit circuit is fine but the receive circuit is not. The fact that it outputs debug information simply confirms that the transmit portion is working but says nothing about the receive section.
- Don Kinzer
Post Reply