ST536 STE EDITION

[exxos]

First test with and without the TTram .... Just proving the disable function is working at this point. TOS206 + BLTFIX and TOSCOPY.

IMG_3274.JPG

IMG_3275.JPG

Weird that VDI text effects is actually slower on the TTram version..

[exxos]

I've enabled the register stuff and it's all gone to crap again. ST and TTram corruption. :roll:

The register is set to DF0000, I've latched the address, ran it though clocked blocks, only way it can issue a data change is if that address is seen. But it must be triggering randomly to corrupt the bus. But how?!

I'm at the point where either my coding is a lot worse than I think. Or this xlinix stuff just doesn't do what it supposed to. Or the PLD is faulty.

I'll have to pipe the address to a spare IO pin to to see if it's triggering next.. Nothing should trigger the address. But it's the only way stuff can happen is when the address triggers.

EDIT:

So I turned it all off. Went for a shower, came back, turned on, and now its booting fine again ?!

I need to fix my SR98 so I can up the voltage as this seems like some odd thermal problem now..

EDIT2:

Freezer spray on the PLD "fixed it" so far...

SR98 with 5.12V on the booster didn't solve the issue...

[exxos]

Seems to be a hotspot on the corner of the PLD somewhere... But even so it shouldn't be out of spec for the chip surely ?!

IMG_3277.JPG

I measured 59c around the same area as well.

I had to do a video on this , because like :WTF:

[exxos]

Like how is the CPU and PLD cooler than the PCB ?!

[dml]

That's nuts.

You really need to use a thermal camera to figure out whats going on there - even then you can get reflections which give false positives so it needs to be done in the dark. Not sure if those laser thermometers get fooled by reflections - maybe not - but it's not specific enough to see what the source is.

Could be a reflection, could be something on the mainboard, could be components on the underside - or even the PCB tracks if something is sinking current to a short.

Most likely its resistors or ICs under the board though.

Also - if the PLD is uncomfortably hot to the touch and the thermometer says its only around 50'c maybe it's not a correct reading on those surfaces?

[exxos]

Yeah proper thermal cams cost a fortune though :( I have questioned it before and even got a thermal probe where I use heatsink compound to couple it. Very messy but generally got consistent results.

I tried with it lots last night. The only thing there is a GND track on the top layer which goes to the CPU ground. BUT in order for it to get hot must mean the inner layer ground "isn't there" and a massive current from the PLD is all going thought the same track. Even so it's a pretty wide copper fill... And every GND pin on the PLD has a via going to the ground plane.

Will post an image later to show what I mean. But while inner copper is thinner than top copper, the impedance of the entire ground plane would have to be higher than the smaller copper gnd fill on the top layer... Seems impossible.. But here we are... :lol: :roll:

There's nothing hotter than 43c on the underside. But there's nothing there other than 2.2k resiator packs. The heat isn't uniform near them anyway. The heat is only topside.

My only thought is maybe the cpu is negative spiking the GND and the PLD sees it as more negative than system GND. Maybe impedance is higher on system GND due to the vias from GND to the PLD GND pins.Top copper goes direct to CPU GND.

I'll have to try and cut that track to prove the hypothesis later...

[exxos]

Grey is copper gnd fill. The highlighted pads on the PLD are gnd points.

gnd.PNG

Then the top copper gnd fill..

gnd2.PNG

So I need to cut that track to separate those GNDs next..


EDIT:

So that wasn't it then :roll:

I checked on the bottom of the board, nothing hot there.. it's all the same temperature..

I can only assume its some sort of measurement error :roll:

[Badwolf]

Sorry, I've not been able to keep up with your thermal problems, but here's a quick report from my own little world.

288 chip. CURRENT9. 47pF on clock.

I've got a return of the IDE reset problem. BUT, cruicially, only when using a mono display. This is perhaps a clue?

I wanted to run some more stress/soak tests, which is generally nicer to do in hi res, so I fitted the Exxos VGA adapter and booted into mono. Up came the EmuTOS splash screen but then rebooted when loading NVDI of (IDE) disc.

Seemed to be repeatable. I thought initially it was perhaps the jumper making a dodgy connecting and flickering the MONO DETECT line, but it doesn't seem to be the case as removing IDE and booting from ASCI works fine (although there was the occasional lockup detecting drives -- could be a separate DMA issue).

Anyway, it's fairly reproducable even though the go-to test of DOTT won't run in mono, going to back to colour lets me boot the exact same drive absolutely fine.

Could the autoboot code somehow be getting involved with the mono detect interrupt and is why we see a (OS driven?) reboot?

Not familiar enough with what's going on with it.

BW

[exxos]

@Badwolf I would see if it behaves without IDE...

On the later boards, I gated IDE CS to the IDE buffers to isolate them. Not sure if that helped, but might be covering up a deeper problem.

Like I said before, its like stuff is being triggered when its not supposed to, like the address is "wrong" and its triggering stuff like IDE during address transitions. Its why I added a CLK100 delay on the address bus and latched it. It seemed to help a lot.

I have just noticed that A0 does not actually have a pull-up on it.. This stemmed back from the original TF536 design.. Debatable how important this will actually be considering is only driving the PLD...

Also probably not a factor but I just swapped the pullups on the address bus to the 5V rail, as they were on the 3.3V rail (same as original TF536). Again its "address related" but im shooting in the dark at this point.

Just one my way to my girlfriends today to give my hands a rest because they are killing me.. But I will probably add a pull-up on A0 when I get back tonight...

[Badwolf]

@Badwolf I would see if it behaves without IDE...

Yes. I don't see resets in mono without IDE per:

as removing IDE and booting from ASCI works fine (although there was the occasional lockup detecting drives -- could be a separate DMA issue).

The "lock up" (freeze on boot probably during drive detection) was an occasional thing during rebootng and only seemed to affect the ASCI bus. I didn't persue that so it could just be a bad connection my end.

BW