ZX-40a circuit problems

[dlh]

I'm using the circuits suggested for the ZX-40a with slight changes - an ST232A instead of MAX232, a 2N2222A instead of 2N3904, ST M95512 instead of the Atmel EEPROM and 18pF caps instead of 27pF for the crystal. All of the components except the crystal are SMD.

With 2 of the first 20 boards I'm unable to communicate with the ZX-40a (I'm using the same ZX-40a for all tests) using the IDE to download my application.

What is the most likely problem? The SMD components and the fact that only one of my arms is useful makes it tough to troubleshoot.

[dkinzer]

What is the most likely problem?

The messages that you are getting, if any, may be useful in determining the cause of the problem. Here are some possible messages and some possible causes:

"Device failed to respond to ATN signal"
The downloader did not get the expected response (a command mode prompt) after toggling the ATN signal. If the ATN circuitry is faulty, the processor may not be getting reset pulses reliably. You may be able to verify this using a logic analyzer or logic probe on the reset input of the processor. Even if the processor is receiving the reset pulses properly, if the transmit circuitry is faulty, the downloader won't see the response that the device is sending.

"Device failed to respond to ATN character (04)"
The downloader did not get the expected response after sending the ATN character. Either the device is not configured for the indicated ATN character or the transmit circuitry is faulty, preventing the downloader from seeing the response.

"Device did not respond to the download command."
In this case, the downloader got the proper response to the ATN signal or character, but when it sent download command it didn't get the expected response. The most likely cause of this is that the device's receive circuitry is faulty, preventing it from seeing the command. However, it could be cause by unreliable transmit circuitry, i.e. it worked well enough to send the ATN response but failed after that.

"Download verification failed."
Here, everything was working well enough to successfully download a program but it wasn't written to Program Memory correctly. The download and verify cycles are identical except that in the former, the device writes the download data to Program Memory and in the latter, it compares the current data in Program Memory to the download data. Verification failure may be due to a faulty SPI EEPROM or the device may not be configured correctly for the EEPROM in use.

[dlh]

"Device failed to respond to ATN signal"
The downloader did not get the expected response (a command mode prompt) after toggling the ATN signal. If the ATN circuitry is faulty, the processor may not be getting reset pulses reliably. You may be able to verify this using a logic analyzer or logic probe on the reset input of the processor. Even if the processor is receiving the reset pulses properly, if the transmit circuitry is faulty, the downloader won't see the response that the device is sending

This is the message I see.

I figure this could be the ATN circuit, the RS232 circuit or the oscillator. Are my assumptions correct?

Getting probes on any circuit points is difficult as they are all SMD. My left hand is partially (mostly) paralyzed and too spastic for holding a probe steady. I bought a ZIF socket hoping I could plug it into the socket on my board and then access the ZX pins with it but it turned out to be 0.100" wider than the socket. I'm thinking of soldering some thin wire leads directly to the ZX pins but will wait until I receive my upcoming order for more ZX-40a chips in case I blow my only one..

My DSO has a 20 Msps sampling rate. That's not quite high enough to see 14 MHz but I think I should still see an aliased signal that will tell me whether or not the oscillator is running.

[dkinzer]

I figure this could be the ATN circuit, the RS232 circuit or the oscillator. Are my assumptions correct?

Yes. However, if the RS-232 circuitry (specifically the transmit portion) is functioning correctly you should see a sign on message immediately after reset. The devices are programmed at the factory to sign on at reset.

Getting probes on any circuit points is difficult as they are all SMD.

Given that the ZX-40a is a 40 pin DIP, you should be able to see the reset pulses on pin 9 if the ATN circuitry is functioning correctly.

I should still see an aliased signal that will tell me whether or not the oscillator is running.

Yes, you should see an analog signal on pin 12 (Xtal2) at 14.7MHz.

[spamiam]

I'm using the circuits suggested for the ZX-40a with slight changes - an ST232A instead of MAX232, a 2N2222A instead of 2N3904, ST M95512 instead of the Atmel EEPROM and 18pF caps instead of 27pF for the crystal. All of the components except the crystal are SMD.

With 2 of the first 20 boards I'm unable to communicate with the ZX-40a (I'm using the same ZX-40a for all tests) using the IDE to download my application.

What is the most likely problem? The SMD components and the fact that only one of my arms is useful makes it tough to troubleshoot.

When you said 2 of 20 boards, does that mean that 18 are OK, or that 18 have yet to be built?

Since you are getting the failed to respond to ATN, then the ATN or the response may be at fault. First check the ATN line and the RS232 signals. Is the ZX sending its hello world on its output pin, but then the RS232 chip is not relaying it further?

-Tony

[dlh]

When you said 2 of 20 boards, does that mean that 18 are OK, or that 18 have yet to be built?

18 are OK.

[dlh]

Yes. However, if the RS-232 circuitry (specifically the transmit portion) is functioning correctly you should see a sign on message immediately after reset. The devices are programmed at the factory to sign on at reset..

Does that come from the VM? These have nothing in the external EEPROM.

[spamiam]

When you said 2 of 20 boards, does that mean that 18 are OK, or that 18 have yet to be built?

18 are OK.

Assembling 20 (or any) SMT boards by hand, with mostly one hand is a real feat!

To test the ATN and RS232 , I'd try to use a clip-on probe on the incoming signals from the computer, then on another channel, try to find a via on the PCB that carries the signal to the CPU. A small-ish probe will be able to nestle its conical tip into the hole of the via relatively securely.

I have been known to thread a small wire thru a via, then solder it into place so I can tap into a PCB trace. Unfortunately those vias are pretty small, so the wire is extremely fragile. If you can do this, then you might be able to do the job one-handed.

-Tony

[dlh]

Actually, I find SMD easier to handle than through-hole. My spinal cord damage is at the base of the neck and the through-hole components mean more craning of the neck and more arm/shoulder movement. Especially with a stencil for applying the paste, SMD involves less of such movement and goes a lot faster. Manually applying paste with a hypodermic is tougher and it's very hard to control the amount of paste dispensed. Long, long away and far ago - before the spinal cord problem surfaced I had above average eye/hand coordination - I always scored extremely high on manual dexterity tests. I suspect the vestiges of that help, even with only one hand.

I've soldered leads to vias, too. Unfortunately, the board house changed their specs - requiring a premium for close tolerances on annular rings. the effect was that I had to make all vias use their minimum drill size (0.016") and then use a 0.040" diameter pad. That make's it really tough to add a lead. I did realize that I could test ATN without having the chip installed. That makes it easy to connect to the socket.

The vary first board I built exhibited the problem. It was already fully assembled which makes rework tough. All the others were partially assembled - just enough to test the program download. It will make rework a bit easier. But I hope to solve it so that I get 100% yield.

At this point, it appears to be the RS232 TX circuit - I'm not getting the sign-on message. But, I still need to test this with one of the good boards to make sure I see it before downloading any program.

I'm using the ST232A with 0.1uF/16V caps. I've never before had a problem but may go to 1.0uF to see if that helps reliability.

[dkinzer]

Does [the sign on message] come from the VM? These have nothing in the external EEPROM.

Yes. The "sign on" flag is stored in Persistent Memory (in the system area) and is programmed during manufacturing test to be True. Just before the VM begins executing code, if the sign on flag is set the VM outputs "ZBasic vX.Y.Z".

Since your EEPROM is initially unprogrammed, the instructions fetched from it will always be &Hff which is a "Halt" instruction.

[dlh]

That doesn't appear to be trustworthy but this may be due to my Windows app which expects a CrLf to terminate each transmission.

With my last board (until more components arrive) I did not see the sign-on when I first applied power. After I downloaded my program, the board operates OK.

I have noticed that the sign-on sometimes precedes my 20+ line initialization report, sometimes not, sometimes it's partial (e.g. asic 2.5.1).

Actually, I guess I can build and test a few more (if my spinal cord will allow) as the only component that I'm missing is a 470uF cap on Vcc but since I'm using a +5V SMPS the missing cap isn't critical for this test.

I really need to run this to ground (or Vcc ) as I want to have the boards manufactured in China after I build the first 100 or so to work out the kinks. There's a picture of an assembled (mostly) board here...

• http://davehouston.org/roZetta.htm