REV 3 - REV 5 - The beginning (ST536)

[exxos]

So not made much progress fixing the rev5. But the annoying thing is now, the latest revision is now being fully :roll:
I swapped my H5 for a H4 and made no odds.

I added in a cache off into TOS for the rev5 and it then passed ROM and TTram check.. But CDIS doesn't seem to help at all now. It's like the fault got worse for no reason like the later rev board. I'm just totally baffled.

The ROM copy errors in TOS startup seem fixed. It seems to show the first word coopied then not the second. BUT, if I can get to desktop and run my ROM verification program, it then verifies fine.. So the copy worked?!

There could be some odd cache issues going on. But you would think during TTram test it wouldn't fail on the whole TTram range.. BUT it will get to desktop and pass every YAARTTT test. It just makes no sense at all.

As things are going from bad to worse, I can only think the constant board swapping is to blame. But this then makes me wonder if the PCBs themselves are just bad. Like bad vias which are breaking more and more as time goes on and its just giving me all these odd faults.

I've half been wondering about trying a different PCB manufacture and maybe even using 2mm thick PCB.. But it wouldn't be conclusive without building up 10 boards to rule out tolerances. It be a rather expensive experiment :(

Only thing I could try is continuity check the whole board. Most internal layers are power planes. So worth a shot. Beyond that I'm out of ideas.

The 536 code isn't even that complicated and I've ran barebones firmware which half the time isn't even stable at 8MHz. But even so, it's like the same weird problems since day 1. It seems the same story.. Everything works fine for ages. Then things just go downhill for no reason.

I mean literally, board works fine for weeks, then just goes nuts never to work again. Same story with the rev5 was working fine then just went nuts. I've resoldered the board, changed the ram, CPU, socket, PLD, regulator.. Still refuses to behave. Plus with my later board just stopped working out of the blue.. What else is left other than the PCB itself failing?

[exxos]

My other latest revision board is working fine.. I forgot I made a second one..

So the first one that was working on now doesn't.. I was just doing some minor changes in the code and it caused TTram not to be found at all.. Which is technically impossible! So for a sanity test I went back to the previous code and now TTram is found and working fine :WTF:

This is the problem all the time because the fault just seems to keep moving around! Other than repeatedly flashing the PLD, and turning the machine on/of , I've not done anything else!

So in true going around in circles fashion – I am back to blaming the wakeup states of the ST chipset somehow causing "something else" to screw up. Something is definitely randomly shifting but I have not yet figured out what.

EDIT:

So I flashed my "last good" firmware, wasn't working, did some changes, wouldn't reset, but the last good firmware back and then it started behaving perfectly !! Went back to my test firmware, would not reset, went back to the last good firmware, TTram FUBAR again. :WTF:

EDIT2:

Now its working again fine :stars: :stars: :stars:

[exxos]

@coonsgm Do you remember if you changed the buffers on the board you sent me ? Just noticed they are different than the ones I fitted on the later boards.. I think those buffers could potentially be too slow and I need to swap them to see that is the problem..

Though I also realised the chips I was going to replace them with (and actually using ) are actually not 5V tolerant parts.. But they are marginally faster...

So now I'm circling right back to the buffers not being fast enough again :roll: the problem being the original ones are really too slow and are actually obsolete now.. Which is probably why I was looking for faster alternatives and "forgot" about the 5V side of things.. But even so, at least gives me a avenue to explore.. Maybe I can to swap them with the transparent buffers like on the H5 if I can get away with those..

[exxos]

Got a bit side-tracked with this thread Looking for a fast voltage translator

Oddly my later board would run GB6 then lockup. Claude has a advanced model. So I gave it all the code and explained the problems, and basically said "fix it". So now its done several passes in GB6 :stars:

It could just be pure coincidence or a total fluke but I could hardly even run GB6 before.

@coonsgm original R5.00 still doesn't like TTram. But different buffers.. Maybe one of the buffers has just gone bad at some point. I will change them for the other types next week and see if it springs to life then or not.

[exxos]

Seems to be running fine on my later board again :shrug:

EMUTOS seems to now be happy(ish) as well. .

It ran GB6 fine..

IMG_4659.JPG

But it really didn't like my ROM shadow copy :shrug:

IMG_4658.JPG

[coonsgm]

@coonsgm Do you remember if you changed the buffers on the board you sent me ? Just noticed they are different than the ones I fitted on the later boards.. I think those buffers could potentially be too slow and I need to swap them to see that is the problem..

Though I also realised the chips I was going to replace them with (and actually using ) are actually not 5V tolerant parts.. But they are marginally faster...

So now I'm circling right back to the buffers not being fast enough again :roll: the problem being the original ones are really too slow and are actually obsolete now.. Which is probably why I was looking for faster alternatives and "forgot" about the 5V side of things.. But even so, at least gives me a avenue to explore.. Maybe I can to swap them with the transparent buffers like on the H5 if I can get away with those..

No I didn't change them. I simply added the BOM items as listed.

[exxos]

The issue on RAMOE enabled all the times issue seems solved now. After tests it's looking like a typo in my bus enable logic for the 16bit bus. If I wire raw RAM decode as a 16bit isolation signal for the 16bit buffers, it won't even boot up. It shouldn't matter really. But the transition of raw RAM decode seems to glitch the buffers.. Oops. I'll need to check the rest of the code for similar mistakes. It was running fine for 2 hours last run.

[exxos]

In true Electronics fashion, one step forward five step back ! :roll:

A previous working ST536.. Flash new firmware.. Would not even boot.. Put the old firmware back... Still no boot.. Swapped to another ST536, works fine.. But the original one back.. Nothing....

Found my little LED diagnostic board and it looks like if I bend the corn of the H5, the LEDS change pattern, otherwise all "high" LEDs are on..

IMG_4661.JPG

IMG_4662.JPG

:sigh:

[PhilC]

You need a 68k zif socket by the sounds of things.

[exxos]

You need a 68k zif socket by the sounds of things.

I've got one but it does not align to the 68K footprint. I need to investigate a proper socket at some point.. But it may not help because the 536 is longer than the socket so it might be physically impossible to activate the lever unless it's a very low profile one but even so it would be difficult to get at :(