Bug Log: Behavior of a Short Between A2 and A15

[+FarmerPotato]

So I somehow shorted A2 to A15/CRUOUT on my prototype board at the side port. On my PCB, the A15/CRUOUT trace went around the A2 pin and traveled next to the A2 trace. My guess is it shorted to the A2 post.

The resulting behavior is: I latch the addresss after memen 1=>0 and phi3=0, when A15 is high, so I always latch A2 high.

On the scope, I can see A2 going low again exactly when A15 goes low.

My question is, does a short on A2 at the side port propagate back into the console? Why does A15 clobber A2 and not the other way around?

For comedic effect, consider that most all the console does at startup is access WS at >83E0, GROM at >9c00, and ROM at >0000 (mostly KSCAN around >0336). If A2 is stuck at 1, these addresses appear to be in the banks >2000 and >a000, at which point a 32k memory expansion is eager to respond, which will lock up the CPU.

A0 A1 A2

0 0 0 console ROM

0 0 1 low memory expansion

1 0 0 PAD and memory mapped GROM, VDP etc

1 0 1 high memory expansion

For further folly, I thought I had fried the A2 input on the CMOS latch (TI SN74LV165A 8-bit shift register), so I replaced it, a surface mount SOIC-16. Same exact behavior, plus I damaged the solder resist over the A2 trace.

[Tursi]

I can't answer your question for certain, but A2 is a true address line while A15 is generated by the multiplexer... the difference in behaviour likely lies in that.

[+FarmerPotato]

I can't answer your question for certain, but A2 is a true address line while A15 is generated by the multiplexer... the difference in behaviour likely lies in that.

 

New Info

While all the digital inputs are consistent with A2 being shorted to A15, I don't have a scope snapshot.

Its possible that I may have shorted A2 to A15 with the probe and captured A15 alone. See pic, A2 A15 shorted.

After cleaning up the board (of several suspicious solder whiskers) I tested again.

A2 and A15 at the side port are distinct.

However, the PAGE output shows the top nybble of the address and reads as if A2 were stuck high.

AORG >7D00

LIMI 0

LWPI >83E0

CLR R0

SETO *R0

AI R0,>2000

JMP $-6

A2  Nybble     -> Page  Context
0    C         -> E     SETO @>C000
1    7         -> 7
1    7         -> 7
0    8         -> A     AI R0,>2000
0    D         -> F     SETO @>D000
1    7         -> 7
1    7         -> 7
1    8         -> A     AI R0,>2000
1    E         -> E     SETO @>E000

I suspect something like, the A15 line is inducing a current in A2 where it goes to U3.

Here is the area of my PCB where they run parallel.

with ground plane (green)

 

I'm going to try something like cutting the A15 trace since I run it north as well, and don't require it in the address latch U3.

Edited December 13, 2018 by FarmerPotato

[Tursi]

I've run my traces pretty tight together without inducing anything that a 3.3v CPLD can see... I'd still be searching for a more explicit cause. Good luck!

[+FarmerPotato]

I've run my traces pretty tight together without inducing anything that a 3.3v CPLD can see... I'd still be searching for a more explicit cause. Good luck!

Thanks for confirming that.

 

Background: U3 and U4 are TI SN74LV165A shift registers which latch the TMS9900 16-bit address from 5V LS TTL, and translate it to 3.3V CMOS over SPI. The SPI transmission completes before the first wait state.

For a board with 48 GPIOs, I attempt to squeeze the whole 4A sideport interface into less than 24 pins, leaving 24 free GPIO pins.

I have ruled out hardware as the cause of A2 being stuck high. I cut the A15 trace to the address latch. Same behavior as before.

I considered for a while if there was an effect from that slot between the two green ground polygons. Because there is a lot of noise in A15 when measured at the console edge (red analog scope trace in the pictures above). Nope, ground planes are connected together adequately.

Noise went away when I cut A15 though.

 

Went to the hackerspace. Nobody else was around, so I spent a lot of time using the stereo microscope to inspect my board.

 

All my effort has at least eliminated noise on many signals like the SPI bus. A big culprit turned out to be an extra 6 inches of ribbon cable on my logic probe, when I switched to a teeny short cable.

 

 

I can watch the SPI bus and see there is no problem with any address bits being latched correctly. The evidence is now that this is a software problem.

 

Time sunk into this is now like 100 hours, clearly a case of premature optimization, changing 16 parallel address bits to 4 bits of SPI + A15, net savings 11 GPIO pins.

I might as well retitle the whole project "Attempt to transmit the 9900 address bus as a SPI frame plus A15."

Edited December 14, 2018 by FarmerPotato

[+TheBF]

Really? A software problem. Never heard of those...

 

I play with vintage microphone re-creation and it's amazing what happens when you listen to circuits that you think are good.

 

It might me interesting to make an audio probe and connected to different parts of the circuit via a small capacitor and listen to the ground plane and other lines that should be silent. The sound of the noise can give hints of where it's coming from and the WSP (wet signal processor) between our ears if pretty sophisticated.

 

Just a weird thought.

Edited December 16, 2018 by TheBF

[+FarmerPotato]

Really? A software problem. Never heard of those...

 

I play with vintage microphone re-creation and it's amazing what happens when you listen to circuits that you think are good.

 

It might me interesting to make an audio probe and connected to different parts of the circuit via a small capacitor and listen to the ground plane and other lines that should be silent. The sound of the noise can give hints of where it's coming from and the WSP (wet signal processor) between our ears if pretty sophisticated.

 

Just a weird thought.

 

Interesting idea about the audio probe. I used to get plenty of audio input through the RF modulator. I can still hear in my imagination the sound of KSCAN running over and over, and the sound of an endless RESEQUENCE.

 

In this case, the scope already tells me much, and the software problem is inside a 100MHz FPGA domain.

[+FarmerPotato]

I found the bug Saturday, but I don't understand it. If I remove the FF initializer or change it to 00, the code works:

Verilog

output reg [7:0] addr;

always(@negedge i_serclk or @negedge shld)
if (!shld)
  addr[7:0] = 8'hff;
else
  addr[7:0] = {addr[6:0], i_q};

There is SOMETHING wrong there that I just don't know enough about. Is it that initializing to ff requires an SR flip flop and something is off in the clock domain? But using 00 requires only a D flip flop and the code works? I dunno.

 

There is more code to generate a shld plus 8 serclk cycles.

This code passes my unit test pattern:

i  shld serclk addr
0  1      1      xx
1  0      1      ff
2  1      1      ff
3  1      0      fe
4  1      1      fe
...
17  1     0     55   
18  1     1     55   PASS

Code links:

https://github.com/olsone/icetea/blob/master/shift_ser_in.v

https://github.com/olsone/icetea/blob/master/shift_ctrl.v

 

In hardware, the shift register leaves some 1s in the high bits. Its like it gets re-initialized or only shifts in 6 bits. If I change the initializer from 8'ff to 8'f0 or remove it, a2 is 0. a2 is stuck when I use 02.

 

If I remove the '!shld' branch, everything works in hardware too.

 

There are two of these 8-bit shift registers, but the order of address bits in is scrambled to simplify PCB trace layout. So the top four bits there are actually a9, a2, a6, a1.

 

PAGE in the scope traces outputs the resulting A0, A1, A2, A3 nybble. Only a2 is stuck high. And a1 has always shown correct for all 8 permutations of A0,A1,A2 address in.

 

I'm going to send the full 16 bits address results out on SPI for further inspection.