REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

The SDRAM code is identical in TF330, TF536, Florica, TF360, TF1260 and TF4060. Its known good.

:thanksyellow: :goodpost:

That's removed a lot of guesswork. Ta.

BW

[exxos]

It always reads 32bits from sdram. even when you ask for 16bits. SDRAM needs to be sync with the CPU so it uses STERM. The 030 does the byte lane sorting.

Without DTACK it just hangs, hence why I added it. I will see if I can do a 32bit read/write to see if its more stable when I get back home.

[terriblefire]

Without DTACK it just hangs, hence why I added it. I will see if I can do a 32bit read/write to see if its more stable when I get back home.

In that case something else is wrong. Check that STERM is wired up in the firmware and then check its wiggles because the state machine in the SDRAM controller should assert STERM for 2 clock pulses at the end of the cycle. If its hanging then thats not happening.

Its also possible that TOS is reading past the end of ram and hanging there.

[exxos]

Its also possible that TOS is reading past the end of ram and hanging there.

That's the odd thing as well, normally it would kick out a bus error, just hanging shouldn't really happen. With using dtack, it comes up random bus and access errors like it's accessing the wrong address, but not sure how that's possible as only the cpu has access to TTram anyway.

I've not touched anything in the sdram code at all either. I'm not allowing TTram access anywhere near a ST bus cycle, so no idea how it can get address errors. It's like the CPU asks for a address but it's the wrong one and causes a error. Can't see how it can happen.

[terriblefire]

That's the odd thing as well, normally it would kick out a bus error, just hanging shouldnt really happen. With using dtack, it comes up random bus and access errors like its accessing the wrong address , but not sure how that's possible as only the cpu has accees to TTram anyway.

I've not touched anything in the sdram code at all either. I'm not allowing TTram access anywhere near a ST bus cycle, so no idea how it can get address errors. Its like the CPU asks for a address but its the wrong one and causes a error. Can't see how it can happen.

You need to explicitly do the bus error on the TF536 because fast memory cycles never make it to the motherboard.

EDIT: By that i mean that the AS, LDS/UDS lines on the motherboard are not asserted and the bus buffers are off when a fast memory cycle happens..

[Badwolf]

Going back to not running FASTRAM.PRG to take any read-past-end or TOS-in-RAM errors out of the question:-

You can choose not to run FASTRAM.PRG and instead, when running YAARTTT choose the (hidden) "M" option from the menu and type in your own address range.

That is what I have been doing... RAM just fails after a few seconds... But running in STOS, assume because the loops are slower, the RAM tests just fine...

What happens if you give it really small range. Eg. 0x1000000 to 0x1000020 ?

If that works, try increasing the range. 0x1000000 to 0x5000000 ultimately.

BW

[terriblefire]

Guys please listen.. that RAM will not work without STERM. If there is hang look for a short on the STERM line or something because it has to latch the data at exactly the right time. DSACK cannot do that.

There is also burst mode that will break. The SDRAM controller will go into a burst but the CPU won't if DSACK is used.

[Badwolf]

Guys please listen.. that RAM will not work without STERM.

I understand that. But you posited:

Its also possible that TOS is reading past the end of ram and hanging there.

This test checks that.

It will also check for shorted address lines, timing malfunctions, precharge issues and if it hangs if you give it a single long, possible missing STERM.

In fact, here's an even simpler test. The attached program reads (and optional writes) a single longword to a given address. If it works at all (on the stock firmware) it's not STERM.

BW

[terriblefire]

Slightly confused though... how are A31 and A30 missing from the CPLD?

I'd recommend removing the fastram logic until you have the rest of the system perfect.

[exxos]

Just got home.. Removed DTACK and STOS and FASTRAM.PRG seem to be working fine now.. no idea why it was acting up before, maybe the CPU is just crapping out after a bit.. I know there is some iffy RAM faults on this board as mentioned before... Sorry for wasting your time @terriblefire @Badwolf ...

IMG_6350.JPG