This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to insure sequential I/O operation with CCSv4

Other Parts Discussed in Thread: TMS320C6457

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

  • 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?

    Thanks 

  • This is a hardware question.  I'll move this thread to the C64x Single Core DSP forum.

    Thanks and regards,

    -George

  • 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.