@coonsgm So that program had a bug it seems and never actually enabled the caches. So please stop that test, and use the updated program here.
REV 3 - REV 5 - The beginning (ST536)
Re: REV 3 - REV 5 - The beginning (ST536)
Interestingly for the first time I have seen the same error...
EDIT:
Same error and same bits a few passes later... So Claude is writing a stress test is to repeat that particular sequence if that can basically error on demand and a list we have a solid starting point for an investigation !
- IMG_5418.JPG (66.05 KiB) Viewed 11 times
EDIT:
Same error and same bits a few passes later... So Claude is writing a stress test is to repeat that particular sequence if that can basically error on demand and a list we have a solid starting point for an investigation !
Re: REV 3 - REV 5 - The beginning (ST536)
Some progress tonight, and for once something that actually repeats.
BUSTEST copies blocks of data between ST RAM and TT-RAM in every combination and checks every byte. With the 68030 caches off, both my board and Greg's pass. With the caches on, both boards fail, and only on copies between TT-RAM and ST RAM. Copies within ST RAM or within TT-RAM pass. On Greg's board it failed badly and then hung, so we don't have the detail from his yet. On my board it fails rarely, but the two errors I have caught tell us a lot.
Both errors were exactly the same. The same byte of test data ($F7) was copied from TT-RAM to ST RAM and came back as $FF. Only one data line was wrong, D11 on the 68000 side (D27 on the 68030), and it read as 1 when it should have been 0. The two errors were at different ST RAM addresses, but it was the same piece of data both times, so this is not random noise. It depends on the data pattern.
The failing byte is always the last part of a misaligned long write to ST RAM. The CPU splits that into three ST bus cycles: a byte, a word, then a byte. It is that last byte that goes wrong. D11 is low in the cycle before it and low in the byte itself, so the line never actually changes, yet it still ends up as a 1. It only happens with the caches on, where the CPU runs those ST bus cycles back to back with no gaps.
So this looks like a timing problem at the point where the ST bus is switched between cycles, rather than a bad solder joint or faulty RAM. The fact that two boards show the same thing points the same way.
I have written a small test program that repeats that exact copy thousands of times a second, so hopefully we can make it fail on demand. That will make it much quicker to test firmware changes and hardware changes, instead of waiting 20 minutes for one error.
BUSTEST copies blocks of data between ST RAM and TT-RAM in every combination and checks every byte. With the 68030 caches off, both my board and Greg's pass. With the caches on, both boards fail, and only on copies between TT-RAM and ST RAM. Copies within ST RAM or within TT-RAM pass. On Greg's board it failed badly and then hung, so we don't have the detail from his yet. On my board it fails rarely, but the two errors I have caught tell us a lot.
Both errors were exactly the same. The same byte of test data ($F7) was copied from TT-RAM to ST RAM and came back as $FF. Only one data line was wrong, D11 on the 68000 side (D27 on the 68030), and it read as 1 when it should have been 0. The two errors were at different ST RAM addresses, but it was the same piece of data both times, so this is not random noise. It depends on the data pattern.
The failing byte is always the last part of a misaligned long write to ST RAM. The CPU splits that into three ST bus cycles: a byte, a word, then a byte. It is that last byte that goes wrong. D11 is low in the cycle before it and low in the byte itself, so the line never actually changes, yet it still ends up as a 1. It only happens with the caches on, where the CPU runs those ST bus cycles back to back with no gaps.
So this looks like a timing problem at the point where the ST bus is switched between cycles, rather than a bad solder joint or faulty RAM. The fact that two boards show the same thing points the same way.
I have written a small test program that repeats that exact copy thousands of times a second, so hopefully we can make it fail on demand. That will make it much quicker to test firmware changes and hardware changes, instead of waiting 20 minutes for one error.
Re: REV 3 - REV 5 - The beginning (ST536)
- IMG_5315.jpeg (311.05 KiB) Viewed 2 times
Re: REV 3 - REV 5 - The beginning (ST536)
So you actually have a different fault than I do then...
Probably nothing else to be done tonight now.. I won't be at home until late evening tomorrow to think about anything else..
Probably nothing else to be done tonight now.. I won't be at home until late evening tomorrow to think about anything else..