Jump to content
FarmerPotato

Bringing up "Geneve 2020": Debugging Help Please!

Recommended Posts

53 minutes ago, dhe said:

That is a short version of the one I recall reading. It's all in there somewhere.

 

Ah, here's the bigger one I remember.

http://www.bitsavers.org/pdf/ti/990/990-10/0945417-9701B_990-10_HWRef_Nov80.pdf

 

I must be thinking of the TILINE interface, which allows for memory transfers both ways between CPUs.

  • Like 1

Share this post


Link to post
Share on other sites

I don't remember all details; it's many years ago that I wrote the emulation.

 

(Just had a short look in the specs...)

 

In general, there are status bits that indicate the completion of a command and the kind of completion (success, failure). You can also set an interrupt for the completion of a command. I'd have to look into the HFDC DSR to check which way it is working.

  • Like 2

Share this post


Link to post
Share on other sites

I think the only place I really remembering DMA work was in the copy command of MDOS. MDOS would check ram free and cut loose DMA Transfer of the files directly into ram - as much as was available - did really phenomenal things with disk copies - suck it all in, spew it all out!  The copy code for MDOS is rather lengthy....

  • Like 1

Share this post


Link to post
Share on other sites

It might be the RAM is not working. I have a bigger test program that does a CRU operation early on.

 

I see the bus state is B, which is UI cycle.  I see that the red trace, ALATCH, skips a beat . That is, the CPU adds a wait state, which it does for all CRU instructions. 

 

 

If I go back a little way, I see the CPU has fetched an instruction from 0018. It writes to 8018, which is R12, then reads from 8018.

Presumably the read from 8018 is the SBZ executing and computing the address.

 

 

Here is the list file:

0018 0018 020C  20  li   r12,lights
     001A 2200     
0019 001C 1E00  20  sbz  0              led

Unfortunately, the address bus in the CRU cycle shows FFFF. Maybe the RAM is not working. (sbz should produce the address 2201. the last bit of addr is MEM which is 1. I didn't display the CRU output bit of 0 here.)

 

Something else is not working. The IO state is supposed to cause the bus signal:

 

Address   Signal

0000-7FFE SERENA*   serial CRU enable

8000-FFFE PARENA*   parallel CRU enable

 

I see neither one. 

 

25647237_J2SERENAnotasserted.thumb.png.6ea34292d18790bbfe11983c81a7913c.png

 

Reviewing the schematic.. PARENA* is broken in a dumb way.

SERENA* would not activate if address is 8000 or up.

I bet that if I troubleshoot the RAM, then I will get SERENA* . but parallel CRU is broken on this version of the CPU card.

I didn't look at the RAM as much as the ROM yesterday.

 

  • Like 1

Share this post


Link to post
Share on other sites
On 11/18/2020 at 12:16 AM, FarmerPotato said:

It's kind of hard for the 99105 to copy its own BIOS ROM into a RAM at the same address space.

Actually, the original Cortex did that, using a technique called "write under". Initially, reads are from ROM, but writes to the same addresses are sent to RAM. Once the copy is complete, the ROM is switched off (using a CRU bit) and both reads and writes go to RAM. There are wait states for slow ROM access.

 

On 11/18/2020 at 12:16 AM, FarmerPotato said:

The DMA feature will work just as TI intended. The essential is that a peripheral takes over the bus for a period, and has full access to read/write the other peripherals just like the CPU would.

Have you considered the TMS9911 DMA controller?

Share this post


Link to post
Share on other sites

 

2 hours ago, pnr said:

Actually, the original Cortex did that, using a technique called "write under". Initially, reads are from ROM, but writes to the same addresses are sent to RAM. Once the copy is complete, the ROM is switched off (using a CRU bit) and both reads and writes go to RAM. There are wait states for slow ROM access.

 

Have you considered the TMS9911 DMA controller?

 

Thanks!

I did not look at the TMS9911, I assumed it would not be obtainable. I was, so far, just implementing HOLD* and HOLDA*, which could be connected to a 9911. But the 9911 fits in with "use real chips". If it's done in the FPGA, it is just a memory-to-memory block move by the DRAM controller, not access to peripherals (and the DRAM transfer would work just by generating wait states, not HOLD*). 

 

I saw something like write-under on a 6502 or Z80 forum. There was one instruction that read through whole range of addresses, perfect for caching. Need a little loop instead.

 

Write-under might not be such a stretch. I have a PLD that drives the ROM*/RAM output switch and bank bits. I could re-purpose the LED bit as the state bit. I have a spare flip-flop and LS125 tri-state gate, that could be used to generate one wait state.

 

I think I just have inputs RD* and WE* and outputs ROM OE* and RAM WE*. If it is in "write under" state, ROM OE*= RD*, and !RD* to RAM's WE*. When in "run state" it sends only RD* to RAM's OE*.

 

write under state (state=0)

ROM OE* = RD*
RAM WE* = RD*
RAM OE* = 1

 

run state (state=1)

ROM OE* = 1
RAM WE* = WE*
RAM OE* = RD*

 

I don't have to squeeze into PLD space for these--just one LS157 will do.

 

Additional logic for whether ROM or RAM page bits are on the high address lines, and RAM CE*. 

 

Share this post


Link to post
Share on other sites

Hobby time has been scarcer lately, but here's a small update.

 

I've changed the crystal to 3MHz, and now the RAM is working fine. So it was just a matter of my RAM being too slow for a 6MHz machine. Going to stay at 3MHz for the time being as it makes testing easier.

 

Last night, I scrutinized every bus cycle of my tiny2 test program, all good. So encouraging. 

 

Tiny2 test used workspace registers, turns CRU bits on (At 6MHz, R12 was failing to read back from RAM) and copies a string from ROM to RAM. I verified each cycle through the logic analyzer. It's tougher because it doesn't capture the whole run at once. But it's repeatable every time, so I just specify microseconds-after-RESET to capture what I want to look at. It ends up in a JMP $ waiting for an interrupt, which I haven't tested yet. I need to make NMI a de-bounced button. Bouncing interrupts suck.

 

Then the front button de-bouncer panel, I re-soldered as a cabled module.   In crimping cables, I've graduated from "sucks less" to "finally adequate". 

 

Oh yeah, the green lighted power switch, picoPSU, ATX power distribution board, and quiet server fan are installed, and work great. Love that physical feedback. The PCB mounting holes were not usable (partly, because PCB mouse nibbles hurt the exact fit.) I just need to re-cut some plastic--not a priority.  (Electronics Goldmine had this box of 24 super-slim server fans for $12!)

 

A 9902 is attached and wired into a USB adaptor cable, so the next, tiny3 test program, will be serial port test code. 

  • Like 2
  • Thanks 1

Share this post


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

A 9902 is attached and wired into a USB adaptor cable, so the next, tiny3 test program, will be serial port test code. 

Sounds like progress. Let me know if you need anything for serial port test code.

I am getting more confident in my cross-assembler output so I could try porting some of my working code into a some kind of repeating string sender if that has any value.

Share this post


Link to post
Share on other sites

Continuing "tiny2 test" 

 

INTA (acknowledge) pin asserts on bus state 5 (INTA)

SERENA pin asserts on bus state B (IO)

 

On RESET, clear LED with SBZ 0

 

String copy to RAM "Hello World!"

Compare string in ROM and RAM

If good, turn on LED with SBO 0

Then JMP $

NMI button works, code turns on LED with SBO 1, returns with RTWP

 

Tests run 100 times with same outcome

 

All tests pass!

 

This concludes tiny2 test.

 

  • Like 3

Share this post


Link to post
Share on other sites


Trying to debug serial I/O.

 

I'm using the AdaFruit FTDI Friend 5V, between the PC and the 9902 (just 0-5V levels. No MAX232 yet.)

 

First I got familiar with logic analyzer capturing bits from the PC TX. 2400 bps, 8N1. Starting off slow.

 

On my board, tiny3.a99 test program initializes the 9902 at >1380. I observed all the CRU operations to load the rate registers etc. I'm confident that all is well on the software side. Logic analyzer captures show it doing all the right things. 

 

Problem is, the 9902 chip select doesn't seem to assert.

 

My CRU decoder is an LS138. One of the enables (G2A*) is my SERENA* signal which indicates CRU access. The other 5 inputs are some address bits.  Y2* out decodes base >1380 and goes to the 9902 chip enable. I can see all the proper inputs but no Y2*...

 

I tried replacing the LS138 and got wackier results. Suddenly, the new LS138 is sucking the SERENA* signal down to 2.5V! That's messing with a '645 driver output from the CPU board. Is it really sinking enough current to screw up the driver? Naturally all the outputs are ~2.5V too.

 

I tested all my LS138 on a breadboard. The original has no Y2* low output, all outputs are always high regardless of ABC inputs. It has been in my board for a lot of test cycles, and it is definitely bad. The other chips test good.

 

So, bad LS138 chip, stable behavior but all outputs high (wrong). Good LS138 chip, erratic behavior and even the inputs get screwed up.

 

Also, a separate LS138 is working as a memory space decoder--no issues there.

 

I checked every socket pin for shorts.. at least at the bottom of the socket. 

 

The first couple LS138 were Fairchild. The first one of those is now bad. All the good chips act erratically, Fairchild and TI brand, plus one TI HCT138. Mostly from Unicorn Electronics. 

 

Maybe the 9902 is bad, and the chip enable is a short. Or worse, not a real 9902...


Ideas?

  1. Remove the 9902 and check the LS138 alone.
  2. Check whether the chip's pins are really making contact? (bad socket)
  3. Re-check all the wires to the LS138 to see if any of them go to dumb places.
  4. Vacuum the boards looking for stray bits of metal.
  5. Go over the board with a microscope looking for bad connections.

 


Here's a snapshot of some CRU activity.

 

 

6675822_tiny3ldcr12bits.thumb.png.bc0de67a2f1964aca8a039dd5b94a25a.png

 

The code. First SERENA* assert is for the sbo 12.

li   r12,>1380
sbo  14        load control register
li   r0,>8B00  8N1
ldcr r0,8
* begin screen capture
sbo  12        skip interval reg, go to reception reg
li   r0,>009c  2400
ldcr r0,11     reception rate register
ldcr r0,11     emission rate register

 

  • Like 1

Share this post


Link to post
Share on other sites

Are all of the enables good? one is supposed to be active-high.

 

High 10k pull-ups on the outputs might help. After doing, that, removing the '138, do you still get erratic values at the pull-up point? caused maybe by the downstream circuit? 

 

 

Edited by jedimatt42

Share this post


Link to post
Share on other sites
21 minutes ago, jedimatt42 said:

Are all of the enables good? one is supposed to be active-high.

 

High 10k pull-ups on the outputs might help. After doing, that, removing the '138, do you still get erratic values at the pull-up point? caused maybe by the downstream circuit? 

 

 

The bad '138, the enables are all stuck high (tested bad on breadboard, outputs stuck high when in the board.)

 

A good '138 (tested on breadboard) becomes erratic in the board. Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.) 

 

Removing the '138 or leaving in the bad one, there is no interference with the bus signals like SERENA*.

Share this post


Link to post
Share on other sites

Yes. Was thinking, it sounds like one of the inputs is floating. Either because you forgot to tie it low or high (G1 input is active high) or because of a bad connection.

image.thumb.png.2637b5afc478787470775b62630792ba.png

Share this post


Link to post
Share on other sites
2 minutes ago, FarmerPotato said:

 Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.)

Can you scope the outputs? If they're sitting at half of VCC then there's a good chance they are oscillating, which would again cause me to suspect floating/unconnected inputs.

Share this post


Link to post
Share on other sites
3 minutes ago, FarmerPotato said:

The bad '138, the enables are all stuck high (tested bad on breadboard, outputs stuck high when in the board.)

 

A good '138 (tested on breadboard) becomes erratic in the board. Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.) 

 

Removing the '138 or leaving in the bad one, there is no interference with the bus signals like SERENA*.

Have you tried decoupling caps on Vcc of the 138 and/or other chips?

Share this post


Link to post
Share on other sites
8 minutes ago, Willsy said:

Can you scope the outputs? If they're sitting at half of VCC then there's a good chance they are oscillating, which would again cause me to suspect floating/unconnected inputs.

I removed the 9902 which sinks Y2* into its chip select.

 

Here the red trace is the Y2* output of the '138, yellow is the G2A* input which is driven by bus signal SERENA*.

They are unusually noisy.

 

This capture is during a TB 27 instruction.

 

BST is bus status from the 99105 (B indicates a CRU cycle)

 

AD is address/data, you only see the address just after ALATCH* goes low. (LSB of an address is CRUOUT, not part of the 16-bit address) The address 13B7 (really 13B6) is the CRU address of a TB 27 instruction.

 

CLKOUT is 3MHz

RDBENA* is the direction of the backplane data bus

WE*, RD* are the read and write strobe

INTA well thats interrupt acknowledge seen right after RESET

SERENA* indicates a CRU cycle.

CRU... is the CRUOUT line.

 

Tiny3 Erratic 138.png

Share this post


Link to post
Share on other sites
11 minutes ago, TheBF said:

Have you tried decoupling caps on Vcc of the 138 and/or other chips?

Hmm, this 138 didnt have its own 0.1uF decoupling cap, but others are sprinkled around the board. Closest, there is one 0.1uF cap on the VCC/GND lines to the 9902, '138, 9906 (same as '259), '125. I removed the 9902, same result.

 

Share this post


Link to post
Share on other sites
2 minutes ago, FarmerPotato said:

Hmm, this 138 didnt have its own 0.1uF decoupling cap, but others are sprinkled around the board. Closest, there is one 0.1uF cap on the VCC/GND lines to the 9902, '138, 9906 (same as '259), '125. I removed the 9902, same result.

 

 

Since that 138 is acting weird I would try one a close to the Vcc pin as possible.

 

Can you see noise on the circuit GND when referenced to a "real" Lo Z ground?

Wild shot in the dark. Is the power supply negative floating?

 

(old analogue guy here. It's where I go first) :) 

 

  • Like 1

Share this post


Link to post
Share on other sites
9 minutes ago, TheBF said:

 

Since that 138 is acting weird I would try one a close to the Vcc pin as possible.

 

Can you see noise on the circuit GND when referenced to a "real" Lo Z ground?

Wild shot in the dark. Is the power supply negative floating?

 

(old analogue guy here. It's where I go first) :) 

 

I inserted the 5V power/gnd wires at the 138 socket, its definitely connected.

 

The current > 500mA indicates something is oscillating (duh) because it was normally around 350mA.

 

1617659921_Tiny3SERENAandB.thumb.png.d8a13a4369a20025e1ea0d81a5b7265b.png

 

Here red is the B and yellow is SERENA*. It seems to be TRYING to go low

A5  >0040

A6  >0080

A9  >0400

A10 >0800

A11 >1000

Selector A2:0 equal to 010 activates O2* (aka ABC and Y2* in TI datasheet)

 

So that actually >1000 to >1300 are aliases, >1400 to >1700 are aliases, and so on. It's just temporary.

671374111_138Schem.PNG.3a29f2ab1ab718e5c38c8fe384980a8f.PNG

Share this post


Link to post
Share on other sites

 

6 hours ago, Willsy said:

Yes. Was thinking, it sounds like one of the inputs is floating. Either because you forgot to tie it low or high (G1 input is active high) or because of a bad connection.

 

I checked the inputs vs the backplane. All are under 0.5 ohms, except G1 which is 0.8 ohms.

Share this post


Link to post
Share on other sites

When I look at the scope output picture(s) I am surprised by some of the signals. It is not clear why CLKOUT should not show a nice regular square wave, and I don't think that the BST lines should change state when the AS signal is low. Is it possible that the scope / analyser is not grounded and hence mis-measuring the signals? If your system is multi-board, is it possible that ground does not feed through? Or a ground loop perhaps?

Edited by pnr

Share this post


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

When I look at the scope output picture(s) I am surprised by some of the signals. It is not clear why CLKOUT should not show a nice regular square wave, and I don't think that the BST lines should change state when the AS signal is low. Is it possible that the scope / analyser is not grounded and hence mis-measuring the signals? If your system is multi-board, is it possible that ground does not feed through? Or a ground loop perhaps?

AS = you mean ALATCH?

 

I've been getting all those glitches in the digital, that are not there when I look at the analog, or use the GPIO as inputs.

 

The VB-8012 is an all-in-one power supply, 2 analog scope channels, 32 digital logic analyser, 8 digital I/O, func generator. When I use the digital I/O lines for clock input, there are no glitches. I have used those for BST and CLKOUT and they look fine. So I think it is crosstalk in the 32-wire cable.

 

I thought it might be crosstalk between the bundle of digital leads (there are 32) which have a 8-inch ribbon cable. So I substituted the short connector without the 8-inch extension, no difference. I lowered the sampling rate, and lowered the logic threshold from 2V to 1V and it got somewhat better.

 

 

 

Ground


From the VB-8012 all-in-one, its 5V/GND power supply goes into my backplane. The logic analyser has 4 ground wires, which I put in near the signals measured. I believe all the WW pins add an extra 0.5 ohm (to both digital lead/gnd.) But that's the only ground loop I can think of. 

 

So I thought I had a common ground reference.   I am not using the grounding lug on the scope. Not sure what I would attach to for an earth ground?  Should it make any difference?  The mains is a 3-prong power cord.

 

There are 2 cards plugged into the 8-slot backplane now: the CPU PCB, and this memory+9902 prototype in wire wrap.   The PCB has a pretty solid ground pour. The wire wrap has a branching ground tree, which goes back to 3 ground pins at the backplane.

 

 

Share this post


Link to post
Share on other sites


I have removed 4 chips (including the 138) and the problem goes away. One LS125 was the only chip with floating inputs, and SERENA was the gate enable (it gates an active CRUIN onto the IN or AD0 pin). Going to put it back together tomorrow.

 

Share this post


Link to post
Share on other sites

Happy to hear that you found the problem.
 

Yes, with AS I meant ALATCH; I was working with a M68K recently and got the signal names confused.

 

Wow, that VB-8012 is a serious bit of kit. Does it have an input mode that adds some hysteresis to the 32 inputs? If so, it could maybe help with the cross-talk. Maybe @Jimhearne and @Stuart have suggestions -- they are much better with hardware issues than I am.

Share this post


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

Wow, that VB-8012 is a serious bit of kit. Does it have an input mode that adds some hysteresis to the 32 inputs? If so, it could maybe help with the cross-talk. Maybe @Jimhearne and @Stuart have suggestions -- they are much better with hardware issues than I am.

I don't see any hysteresis option. Just the sampling rate and threshold. Lowering the sampling rate helps.

 

I guess the other thing would be to construct a debug board with buffers. I don't know of a Schmitt trigger other than '04 or '14 inverters (so double up?). Maybe a row of LVC245A that I use a lot of (to connect to 3.3V chips). These have a rise time of 10 ns/V and might eat the glitches.

 

 

The VirtualBench was rolled out to university labs while I worked at NI. I had a small part rolling it out to TechShop. I got this one for the employee price. Otherwise, buying separate tools would probably have had an advantage, except for convenience. It's a PITA to write automated tests in LabVIEW, but I've done it for my PLDs. (NI=National Instruments, not Texas Instruments, not National Semi (now part of TI), NI=Not Into making calculators since 1976!)

 

 

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...