REV 3 - REV 5 - The beginning (ST536)

[exxos]

On this board (another TTram fault)

IMG_4806.JPG

I wrote a STOS program to cycle bits.

IMG_4808.JPG

Gave copilot a try.. it said..

Lower 16 data bits (D0–D15) work → the “low” SDRAM chip is behaving.

Upper 16 data bits (D16–D31) don’t store what you write → the “high” SDRAM chip (or its CS/WE wiring) is not actually participating in writes/reads.

One bit in that upper half—what the CPU sees as bit 17 (0x20000)—is stuck high.

I wrote another STOS loop to just toggle all 0 then all 1 on one address. D0-D15 show activity. D16 -D31 just seem to be floating high. So would seem something is broken with one of the SDRAM chips.. and they are new chips as well..

[exxos]

Continuity checked the SDRAM chip and seemed fine. Changed it anyway. Now getting other "bad" results :roll:

IMG_4812.JPG

Only thing I can do is change the data buffers because there is nothing else in that part of the circuit now. :roll:

[exxos]

Changed the SDRAM.. Then changed the 2 buffers..

IMG_4810.JPG

IMG_4813.JPG

I don't get it.. Nothing is wrong, everything beeps out.. Changed the chips.. I will have to try and scope the DQM lines to see if they are actually changing next.

Why can't something just be simple for once !

:dizzy:

[exxos]

I wrote a bit pattern to $4000000 and got this back..

20260313_223836.jpg

Its like the lower bits are somehow copying to the higher bits.. But not always.

Even more odd, when I get to $4000006 write and read values match..

Anyone have any idea what's going on? I ain't a clue.

[exxos]

8bit access seems to work.

20260313_225514.jpg

20260313_225457.jpg

[exxos]

These are long word writes...

I write 00AAAAAA, 00555555

20260315_232739.jpg

Then 55555500, AAAAAA00 with simialr results.. Image I took of that vanished :shrug:


Then AAAAAAAA, 55555555

20260315_232829.jpg

So only specific bit patterns seem to fail..

BUT I don't think that's true because it looks like the low and high words get mirrored somehow..

So while I get back 550055 I'm writing 00555555 which the high byte gets mirrored to the low byte 0055 0055. The leading zeros get trimmed in STOS, so the result ends in 550055.

So how the heck does the high word get copied to the low word?!

[exxos]

I think I'm getting ever increasingly closer to giving up on this project. More I look into it the more weird things I find and the more things make no sense.

Currently the STERM is pulsing like a slow clock signal. 200ns low, 300ns high.

STERM is basically.

Code: Select all

always @(posedge CLKCPU or posedge AS30) begin
    if (AS30 == 1'b1)
        STERM_D <= 1'b1;
    else
        STERM_D <= WAIT_BLOCK;
end

ACCESS (ram_decode for TTRAM) I have that output to a spare IO pin to my scope. Its mostly high as expected without any TTram access.

BUT if I do this :

Code: Select all

always @(posedge CLKCPU or posedge AS30) begin
    if (AS30 == 1'b1)
        STERM_D <= 1'b1;
    else
        STERM_D <= WAIT_BLOCK | ACCESS;
end

There is no way STERM can go low when ACCESS is high right ? WRONG ! STERM pulses like a clock even though ACCESS is confirmed high on my scope.


YELLOW - CAS
LIGHT BLUE - ARAM4
PURPLE - STERM
BLUE - ACCESS

IMG_4827.JPG

I even traced AS30 (BLUE) vs STERM (PURPLE)

IMG_4826.JPG

By all accounts it should be statistically impossible for this thing to even boot up under that situation ?!

I even went right back to the original TF536 SDRAM code and get the same issue but its unstable. So didn't look into it any more.

So basically the laws of physics don't apply any longer...

[exxos]

I connected up a different board and I don't get those weird problems.. So that STERM issue is only on @coonsgm rev 5.00 board. But I wonder if those odd TTram errors are malfunctions in DQM as well.

I double checked PLD power rails and everything seemed connected. I can only think that there is actually a faulty via on a power rail on the PLD somewhere causing some logic blocks to malfunction. So I will just have to retire that board because I cannot find the problem with it :( I think at this point, the 5.00 boards are discontinued. We moved ahead to the 5.50 boards, not sure how many are out there. Likely not many as store still showing 7 boards in stock.

So does look like the clock does need rerouting after all. I actually put that in the instructions as a mod, then decided against it for some reason, now we are back to needing a mod again :roll:

Started looking at my other two 5.50 boards. One had a hairline crack on one of the ST databus lines. That one now boots up. The other one needed a repair on the SDRAM clock. Thats now soak testing TTram. I don't think theres any issues with the 5.50 boards overall.

The 5.62 boards I added more caps mostly. Moved to a better regulator, but missed the enable wire off the regulators. Those won't get into store until the 5.50 boards have all sold. But won't be many of those as I need to build up a couple more for testing.

The odd STOS lockup problems were "self inflicted". I tried to push CPU time in 50mhz as much as possible. While it would run TTram and GB6 for days without issue, STOS for some reason was unhappy. I had to removed those changes for STOS to work again. I assume STOS used its own floppy routines. I have asked in the STOS code is Facebook group, but so far nobody has applied. Probably not an easy question to answer anyway..

I've started on a rev 5.63. This one has the inline series resistors in the ST bus side. I've also been doubling up on Via's on the PLD power pins just in case.. I've also added pullups on the SDRAM data pins. It just gets on my nerves when I am trying to look for switching low lines when they are floating all over the place ! It should help keep noise down not having them switching all over the place. I also increased the via size with the thought that larger ones should be more reliable. That was a significant routing challenge , because there is basically no room anywhere..

563.PNG

[exxos]

Today's weird fault...

ROM copy message appears twice, I don't know how that is even possible either !

ROM to TTram verify generally succeeds indicating TTram is fine.. But TOS won't get as far as TTram test.

IMG_4843.JPG

Been doing a few experiments in firmware and if I disabled TTram totaly, it would run GB6 from STram just fine. I continuity checked the CPU to PLD to SDRAM to 68K headers.. checked power, all fine.

So now that board seems to died completely.. It seems to start running ROM as it turns the screen green , now just locks up.

IMG_4846.JPG

I sprayed the whole board with freezer spray and made no difference. This board was working perfectly fine the other day!!

I really don't get why these weird faults keep happening. It's like something just simply keeps deteriorating. :shrug:

[exxos]

After comparing a working board and the now dead board, the dead board PLD is getting noticeably hotter at one side now. I removed the SDRAM and buffers in case something had failed there but made no odds. That board was working fine a few days ago.

I was thinking about changing the PLD, but I still wonder if the PCB is damaged or other parts anyway. And those PLD's are not cheap to keep doing experiments with them ! I envision I will be soldering a working chip onto a faulty board and probably killing it again..

So I got sidetracked into looking into if ultrasonic cleaners can damage boards

viewtopic.php?t=8248


What I will probably do, is build up another REV 5.50 board next, and NOT use a US cleaner at all on it. Then see if it starts to develop odd faults like some other boards have.