Hello,
Are there any compiler flags , assembler drectives and such that would enforce sequential I/O operations? I am coding with Code Composer
Version: 4.2.3.00004 for a TMS320C6457 DSP. My C code performs 3 I/O write instructions followed by an I/O read ( All to EMIFA Ce3 space actually ) , but i observe with an oscilloscope that what actually happens is two sequential writes , then a read , then the third write. This ultimately causes a "bad device id " to be read from a programmable device in that space. However if i single step the code - the operations perform as coded - and a valid device id is obtained.
Any help would be appreciated
Thanks
Use the volatile keyword to indicate a variable is associated with an address that is special to the hardware. The compiler accesses volatile locations in the same order as the original C source. The volatile keyword is a storage class modifier like extern. For more background info, do an internet search on "c volatile".
Thanks and regards,
-George
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
George,
The volatile keyword did not help the situation. The specified operations were being executed without being declared volatile. It's the order of those operations , that was inconsistent. Single stepping with an emulator , accesses the I/O in the correct order , while running the code full speed produces the out-of-order execution. somehow the fetch packet for the I/o read is executing before the third I/O write. Is there any way to force the processor to execute fetch packets in sequence?
This is a hardware question. I'll move this thread to the C64x Single Core DSP forum.
No experience with your processor. On other processors, I've seen pipelining causes reordering of instructions. Don't know if your processor has a pipeline. Cacheing can cause grief with peripherals where you write to one register that will cause a change to another register that is immediately read back. The read will finish faster if there is a cached value. You could try invalidating the cache(s) between the writes and the read.