Jump to content

Photo

Bug Log: Behavior of a Short Between A2 and A15


7 replies to this topic

#1 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 218 posts
  • Location:Austin, TX

Posted Wed Dec 12, 2018 10:26 AM

 
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.
 
 


#2 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,423 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Dec 12, 2018 3:25 PM

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.



#3 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • Topic Starter
  • 218 posts
  • Location:Austin, TX

Posted Thu Dec 13, 2018 1:51 AM

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.
A2 shorted To A15
 
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.
A2 A15 Not shorted
 
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.
 
PCB A2 A15
 
with ground plane (green)
PCB A2 A15 GND

 

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 by FarmerPotato, Thu Dec 13, 2018 2:01 AM.


#4 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,423 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Dec 13, 2018 3:55 PM

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!



#5 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • Topic Starter
  • 218 posts
  • Location:Austin, TX

Posted Fri Dec 14, 2018 10:55 AM

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 by FarmerPotato, Fri Dec 14, 2018 11:04 AM.


#6 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 854 posts
  • Location:The Great White North

Posted Sun Dec 16, 2018 9:02 AM

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

 

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 by TheBF, Sun Dec 16, 2018 9:07 AM.


#7 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • Topic Starter
  • 218 posts
  • Location:Austin, TX

Posted Mon Dec 17, 2018 10:56 AM

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

 

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.



#8 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • Topic Starter
  • 218 posts
  • Location:Austin, TX

Posted Mon Dec 17, 2018 11:20 AM

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/o.../shift_ser_in.v

https://github.com/o...er/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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users