TEST and CRC run very slow when clock missing

[jessaskey]

I noticed that when I was testing some scripts via the serial port for batch testing, that if the ICE is on a powered down UUT, that these two command will run (which is good), but they are about 100-200x slower. A 'test 0000 0FFF -1' takes about 1 second in place of my 6502B CPU, but when I have the ICE on my PC via USB with no UUT or the UUT is turned off, it will take over 3 minutes to return.

Any chance that if the ICE is in missing clock mode if these can auto clock or just return a zero result in order to complete in a timely manner?

[hoglet67]

The timeout (per access) is I currently fixed and is about 4ms.

I think the best option here is to add a timeout command, and make the timeout programmable.

I can have a go at that today.

[hoglet67]

I've added a timeout command that takes a parameter in microseconds (in hex): https://github.com/hoglet67/AtomBusMon/commit/944f951b189543b0b168ded383fa408a6a50392c

In testing this I was powering the host on and off, and a couple of times I seemed to get stuck in a state where I was seeing "memory timeout" errors, even though the host was running.

I don't think this has anything to do with making the timeout programmable. I suspect there is a hardware bug where the memory state machine can end up stuck in an undefined state, possibly due to an unexpected/asynchronous input change. Do let me know if you encounter this issue, and I'll put a bit more effort into tracking it down.

(for reference I saw it with the ICE-65C02)

[jessaskey]

thank you... I will grab dev tonight (US time) and give it a runthrough. I was also seeing the memory timeout messages (for crc specifically I believe) but they appeared to be sporadic and the response time did not seem to depend on if there was a memory timeout or not. I will do so diagnostics tonight and report back.

[jessaskey]

Okay, this seems to have worked pretty nicely, thanks again. I tried this evening to find a pattern when the memory timeout message appears and I wasn't really able to find anything. I was able to get the 6502 ICE to basically quit responding using these commands (not connected to a UUT).. UPDATE: Oddly, the ICE finally responded after like 10 minutes.. see the very end of the post...

NOTE: Nothing below is very meaningful because I had the ICE not plugged into a DUT, so I think in those circumstances 'mileage may vary' is perfectly acceptable. I never was able to get a memory timeout this evening tho.

I had the timeout set to 100 I believe if that effects anything. I was a bit perplexed on the 'passed' result of the memory tests when trying both 00 and FF. I figured that the 00 would always pass and FF always fail without being on target hardware.

c CPU free running... Interrupted 00.364675 : FFC3 : 00 : BRK missing clock test 0000 00ff 0 Memory test: Fixed 00: passed missing clock test 0000 00ff ff Memory test: Fixed 00: passed missing clock crc 8000 ffff Illegal command: crc 8000 ffff crc 8000 ffff Illegal command: crc 8000 ffff test 0000 00ff -1

Not sure why, but after the 10 minutes, I got a test going from 0000 ffff with these messages...

Fail at FFEB (Wrote: 55, Read back 00) Fail at FFEC (Wrote: 55, Read back 00) Fail at FFED (Wrote: 55, Read back 00) Fail at FFEE (Wrote: 55, Read back 00) Fail at FFEF (Wrote: 55, Read back 00) Fail at FFF0 (Wrote: 55, Read back 00) Fail at FFF1 (Wrote: 55, Read back 00) Fail at FFF2 (Wrote: 55, Read back 00) Fail at FFF3 (Wrote: 55, Read back 00) Fail at FFF4 (Wrote: 55, Read back 00) Fail at FFF5 (Wrote: 55, Read back 00) Fail at FFF6 (Wrote: 55, Read back 00) Fail at FFF7 (Wrote: 55, Read back 00) Fail at FFF8 (Wrote: 55, Read back 00) Fail at FFF9 (Wrote: 55, Read back 00) Fail at FFFA (Wrote: 55, Read back 00) Fail at FFFB (Wrote: 55, Read back 00) Fail at FFFC (Wrote: 55, Read back 00) Fail at FFFD (Wrote: 55, Read back 00) Fail at FFFE (Wrote: 55, Read back 00) Fail at FFFF (Wrote: 55, Read back 00) Memory test: Fixed 55: passed