Hmm. I can't see anything obviously wrong in the code.
So the theory that the timer stops for a couple of cycles during chaining seems like the most likely explanation. There's no mechanism to explicitly enable/disable the timer, nor to read its value, so maybe it's stopped as a power saving measure when not in use by any channel, and there's then a couple of clocks delay between one channel finishing and the chain kicking off another one.
You could prove this experimentally by using a third channel - since the timer can be used by more than one channel, you could set up a spare channel paced by the timer and doing nothing (eg. moving a word from RAM to RAM with no auto-increment, with an 0xffffffff transfer count so that it doesn't stop within the time taken to run the experiment). That should ensure the timer is always in use and never stops. But not actually a sensible solution for real use.
So the theory that the timer stops for a couple of cycles during chaining seems like the most likely explanation. There's no mechanism to explicitly enable/disable the timer, nor to read its value, so maybe it's stopped as a power saving measure when not in use by any channel, and there's then a couple of clocks delay between one channel finishing and the chain kicking off another one.
You could prove this experimentally by using a third channel - since the timer can be used by more than one channel, you could set up a spare channel paced by the timer and doing nothing (eg. moving a word from RAM to RAM with no auto-increment, with an 0xffffffff transfer count so that it doesn't stop within the time taken to run the experiment). That should ensure the timer is always in use and never stops. But not actually a sensible solution for real use.
Statistics: Posted by arg001 — Sun Jul 07, 2024 10:23 am