We use the CF bus to read and write to registers on our hardware device. The debug build of our software has extra code at each read/write cycle that makes the operation take longer. When we switch to release build, the extra code is no longer there and the read/writes will execute more quickly.
The problem we are finding with the read/writes acting very fast is that only a few of them are actually make it onto the bus when we do rapid reads/writes together. The rest just "disappear" even though they appear to return successfully.
Hi Rob: Can you let us know what values you are using for the MECR register? Maybe it's set too fast for your hardware.
We've tested the CF memory on an SRAM card with the Fast bit set, and it worked with the card at speed settings as fast as 0x02 (see test results at topic 862).
It looks like the issue wasn't bus timing. As they reported, "Our best guess is that the processor was optimizing identical reads and writes to the CF bus by caching them and skipping operations. That works fine for normal memory, but not for accessing a device register whose contents may change for sequential reads.
"The bus timing changes did not seem to affect it. But we stumbled upon a solution that seems to force the processor to output a read and write every single time. We did this by making our reads/writes a function call instead of direct memory access through a pointer. It seemed to do the trick!"
Declaring the pointer as a volatile may also have fixed it as well. Using volatile, forces the application to always read from memory. See this article for more information about using volatile.