Jump to content
FarmerPotato

Bringing up "Geneve 2020": Debugging Help Please!

Recommended Posts

On 1/2/2021 at 5:03 AM, pnr said:

Happy to hear that you found the problem.
 

 

Well, it is not solved.  I can sample SERENA* with the hi-Z analog probe or digital probe. As soon as I connect a gate input, it fails. Both LS and HCT. The driver is an ALS138A output (decoding the IO bus state and A14:13). As far as  I can tell, it should be compatible.

 

My last ideas are

1. try a buffer on breadboard, see if it has the same issue with output drive.

2. desolder the ALS138A driving it--this was not meant for a bus driver, but I cheated rather than add another line driver (which I clearly must do in the next pcb rev).

 

I've ordered all the combinations of new 138 parts--my stock is used up.

 

Share this post


Link to post
Share on other sites

Try adding a 2N7000 or something similar to drive the signal. Worth a try if you have a MOSFET lying around...

Share this post


Link to post
Share on other sites
20 hours ago, FarmerPotato said:

Well, it is not solved.  I can sample SERENA* with the hi-Z analog probe or digital probe. As soon as I connect a gate input, it fails. Both LS and HCT. The driver is an ALS138A output (decoding the IO bus state and A14:13). As far as  I can tell, it should be compatible.

Maybe it is not a DC but an AC issue: maybe the bus line is ringing? Have you tried a 100R series resistor to dampen reflections (as in the firehose interface)?

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, pnr said:

Maybe it is not a DC but an AC issue: maybe the bus line is ringing? Have you tried a 100R series resistor to dampen reflections (as in the firehose interface)?

OK, I'll try a resistor.

 

I considered whether to add the 220/330 ohm bus terminator packs. I see these on the S-100 bus. A fellow in our retro club here says that's not really needed with a 6" bus and 6MHz.

 

I wonder what capacitance is added when I insert the 138 that is using the input. I think this is in the datasheet somewhere...

 

I have replaced the ALS138 driver with a new LS138. The new LS138 is driving the bus SERENA* perfectly but is there really a load on it? The sink LS138 is not adding any current draw to the total! And all the outputs are low, yikes. Not a short? Maybe fried? I should test the chip separately, after I see this.

 

I tested continuity through the chip socket itself, in case the contacts were weak.

 

Goldang it, both the VCC and GND pins do not have continuity between the chip and the wire wrap pins! The WW socket contacts must be worn out.

Unkown if it's from Unicorn, or some surplus shop, or worst case, from TI's dumpster and used already.

Spraying some Deoxit in there before I pull it out.

 

Spoiler

I was surprised by how easy hot-air *rework* is. Flux, no Capton tape, no solder wick, no sucker, no extra solder! The original soldering was pretty difficult. (Except for the 99105, the cpu card is all SOIC-16 and the like.)

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 1/2/2021 at 5:03 AM, pnr said:

Happy to hear that you found the problem.
 

 

At last it is fixed.

 

The wire wrap socket of the LS138 was broken at the VCC and GND pins (only!) I replaced it with a new, machine pin WW socket. 

 

 

  • Like 4

Share this post


Link to post
Share on other sites

Here is the "clean" screenshot. Yellow SERENA* is from the CPU card to the '138, Red 1380 is the Y2* output to enable the 9902.


AD and ALATCH show CRU address 13B6 being latched. (ignore the LSBit)

IN is 1, from the 9902. With no chips inserted, it would be floating or 0.

 

 

35084476_Serenacorrect.thumb.png.f30e01c4476c19a808748aac91e9fa4c.png

 

Glitches remain. I don't see much when I look at the analog. At sampling rate 125 MS/s they are repeatable.  But not at 50 MS/s; they dance around. I conclude that the glitches are at least 8 ns and shorter than 20 ns. With glitches appearing on RESET*, the cpu keeps on ticking, so they can't be real. (But then again that is too fast)

 

 

The RESET* line is driven by a debounced switch, with an RC decay time and two series Schmitt Trigger inverters (74LS14). The debounced switch is rock solid over 50 presses, each recorded in a 200ms window. (It needed a decoupling cap on the LS14 to fix ringing.) The 99105 has Schmitt trigger inputs but those are now redundant. I've spent more time hand-soldering on that #@! reset switch...

 

Onward to debugging serial!

 

 It is in a tight loop (comments mostly from Thierry's code)

 

0035 002A 020C  20        li   r12,conr12
     002C 1380     
0036 002E 1F1B  20 lp1    tb   27               test dsr pin (i.e. dtr on the connector)
0037 0030 16FE  14        jne  lp1              line is high
0038 0032 1F15  20        tb   21               line is low: test receive buffer
0039 0034 16FC  14        jne  lp1              else keep waiting

 

 

TB27.thumb.png.16f52019dce712afc1346f8d86f1e849.png

Address 13B7: (ignore LSbit)

TB 27 finds 1 for DSR* low.

DSR* is pulled low by 10K resistor (my 4-wire cable has no DTR) indicating online.

 

Address 13AB:

TB 21 finds 0 for no character in receive buffer.

TB21.thumb.png.b096883bf9cf2adbf6580fe61ceb4eca.png

  • Like 1

Share this post


Link to post
Share on other sites

Again, congrats on getting it to work!

1 hour ago, FarmerPotato said:

With glitches appearing on RESET*, the cpu keeps on ticking, so they can't be real. (But then again that is too fast)

This by itself is not certain. My understanding (after experimentation) is that reset is only sampled by the CPU on the rising edge of CLKOUT. Although the datasheet says that it must be asserted for at least 3 machine cycles (clocks), actually one is enough for the processor to reset. If the glitches occur outside the setup/hold time around the clock edge, the CPU would not notice.

It may be interesting to do an analogue measurement for CLKOUT an RESET and see how that relates to the digital measurements. 

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, pnr said:

Again, congrats on getting it to work!

This by itself is not certain. My understanding (after experimentation) is that reset is only sampled by the CPU on the rising edge of CLKOUT. Although the datasheet says that it must be asserted for at least 3 machine cycles (clocks), actually one is enough for the processor to reset. If the glitches occur outside the setup/hold time around the clock edge, the CPU would not notice.

It may be interesting to do an analogue measurement for CLKOUT an RESET and see how that relates to the digital measurements. 

1565203269_ResetGlitch.thumb.png.493d682ea670b051d05b75173c0e95a3.png

 

RESET* is clean in analog.

I wonder if this is an issue with my digital harness (about 7" of wire) or the VB-8012 itself. It has continued across firmware updates.

I pushed the probes on more forcefully and it seemed to get a little better.

 

Addressing the VCC ripple,

I added some more bypass 0.1uF caps.

I see the VCC ripple is present in the CLK ripple, or is it the other way round? 

 

It's tempting to think the biggest VCC ripple coincides with an ALATCH glitch.

 

1629801856_Clockripple.thumb.png.06c50c3abff8293ad8f0fcb2291f3914.png

 

Stats say that VCC  min/max peak to peak is 1.15V

A different stat says Voltage 4.8 to 5.31.

 

A VCC that occasionally touches 4.5 or 5.5 is not a good thing. but 4.8 to 5.31 is sort of ok.

 

The CPU has one 0.1 cap just outside VCC.

 

RDBENA and RD seem to match the demand on VCC, as the bus buffers switch direction. Those chips also have 0.1uF caps on VCC (on the cpu pcb)

 

Share this post


Link to post
Share on other sites

Well, the analog shows that the signals are as I would expect them to be. Had a quick look at the spec sheet for the VB-8012:
https://www.ni.com/pdf/manuals/371527d.pdf

It says that the input threshold on the digital inputs can be adjusted between 0V and 2V. For TTL signals I think low is 0-0.7V and high is 2.4-5V. Maybe the threshold is currently set to a quite low or high value), where overshoots are detected as a reverse signal for one sample. Mathematically, 1.5V should be ideal, but in a circuit that mixes (LS-)TTL, HCT, NMOS, etc. some experimentation may be in order.

Share this post


Link to post
Share on other sites
On 1/9/2021 at 10:20 AM, pnr said:

Well, the analog shows that the signals are as I would expect them to be. Had a quick look at the spec sheet for the VB-8012:
https://www.ni.com/pdf/manuals/371527d.pdf

It says that the input threshold on the digital inputs can be adjusted between 0V and 2V. For TTL signals I think low is 0-0.7V and high is 2.4-5V. Maybe the threshold is currently set to a quite low or high value), where overshoots are detected as a reverse signal for one sample. Mathematically, 1.5V should be ideal, but in a circuit that mixes (LS-)TTL, HCT, NMOS, etc. some experimentation may be in order.

Yes, I've played with the 0-2V settings, it didn't affect it as far as I can see. I think the glitches are in the probe wires or the digitizer chip. I don't get any such glitches when I use a GPIO pin.

 

I'm going to focus on cleaning up VCC with bypass caps--I've got a measly 0.1 on the 99105. The last couple 0.1 uF didn't affect the noise on CLKOUT, but I'm not sure if that is coupled from VCC or just the way NMOS square waves come out. 

 

I'm keeping measurements on CLKOUT as I add bypass caps, for specific frequencies.

 

image.thumb.png.a5c8e947ddc08331460374243f73df99.png\

FFT of CLKOUT.

 

Blue=before

Orange=after adding 0.1uF on each remaining IC. No effect.

Square wave of 3MHz should have harmonics at 9,15,21. There's a pretty big ripple at 6 that I'm watching.

 

 

 

 

Share this post


Link to post
Share on other sites
On 1/7/2021 at 4:39 PM, FarmerPotato said:

At last it is fixed.

 

The wire wrap socket of the LS138 was broken at the VCC and GND pins (only!) I replaced it with a new, machine pin WW socket. 

 

 

Goldang reset button flaked out again. A solder ball on the LS14 (inverter with Schmitt trigger inputs) broke free. The LS14 has two unused gates, 6 and 1, which must not be left floating.

 

Input 6A was tied to VCC, output 6Y was giving 0V as it should, but the teeny wire connecting 6Y to feed input 1A was separated.

 

The symptom was that input 4A was a solid 0V, but output 4Y was an erratic around 2.5V.

 

A demonstration of how floating inputs can mess up other gates in the same chip (floating gate 1 screwed up gate 4). 

 

That's what interrupted my testing of 9902 bits on Saturday. One moment it was working, then #@[email protected]$#!. Broken solder ball.

 

EDIT

 

Multiple issues existed. As I started putting components back together in a system, the RESET line flaked out. Button panel by itself, fixed. Button panel + CPU, erratic. Repaired one crimped lead, and cleaned up solder joints, fixed. CPU + Button panel working perfectly. Attach to backplane with memory board, same erratic again! Inspected RESET pin at memory card... no obvious short. Corrected a slightly bent GND pin next to it. Perfect!

 

I don't know what the bent GND pin could have to do with it. It bends away from the RESET pin and goes into a 3x32 pin backplane socket! Maybe bad stuff happens inside the socket. I'll have to take one apart.

 

There is no other connection to backplane RESET. It's a backplane input to the cpu card. CPU card asserts  RESOUT* on  the backplane, when it enters a reset bus cycle. RESOUT* is for the reset inputs of cru, video etc.

 

All back to normal now though. No more time this evening to test serial bits, though.

  • Like 5

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...