HYPERRAM: production_test fails with release-0.96 candidate

[lydon42]

While adapting r3_production_test to the new boards by rewriting it into production_test (see mega65-tools#190), HyperRAM kept failing on both r3a an r5 boards.

I adapted test_585 (old HyperRAM problem issue) to include the cache invalidation the production test does, but 585 behaves more stable by giving a good result nearly every time. But it did also fail on me (might be a false positive due to the state the machine was in at the moment -- alternating between test_585 and production_test via rapid etherload pushes).

Switching HyperRAM from the default slow_cache_enable to 0 does improve success rate. With slow_cache_enable and slow_cache_advance_enable it will fail every time.

SDRAM test works as expected on r5.

So it seems we do have some problem with HypeRAM.

I did test versions before the 683-cartflash merge, and they behave the some, so there is no regression from this side, as far as I can tell.

[markkrueg]

Happening 100% of my production_test runs on my r3a batch 2. Zero failures running test_585.prg (over 10 runs so far).

[markkrueg]

I'm not sure if this is meaningful; but if I run production_test, see FAIL HyperRAM, then hit reset button and immediatly run test_585 then it fails every time. I can only run test_585 successfully on a clean power cycle where I have NOT run production_test. Using "etherload.osx -4 -r test_585.prg"

[lydon42]

Since 0.95 the meaning of the end of 64MB area starting at 8MB has changed for HyperRAM: 0xbfffffx is used by some registers used for debugging.

The r3_production_test used to poke 0xbfffff2 to bust the line cache of HyperRAM, and now this seems to break HyperRAM in various ways.

We need to fix the tests (over in mega65-tools) and perhaps add some information about the memory area here.

[markkrueg]

All tests working perfectly now using updated versions provided by @lydon42.