Question: Message " Emulator processor access time-out " message in the emulator command window ?

Answer: There are two basic causes:

• The device is in reset.

Attempts to execute (single-step or run) a program when the DSP is in reset may cause the "Processor access timeout" message to be displayed in the COMMAND window.

The device will always "time out" when "running". When single-stepping the situation could be dependent on the DSP silicon version you are using. For example, in the case of the C4x PG2.x silicon, you may be able to step without the error message. That is not the case in PG1.x or PG3.x or above.

• A current access that is being truncated.

The debugger will break any pending CPU/DMA access that is not completed within a time-out period (1 second) during single-stepping or after an emulator halt. This could happen in the following situations:

I) Access to a device peripheral that is not ready. For example, in the C4x:

     + When DMA/CPU reads from an empty IFIFO.
     + When DMA/CPU writes to a full OFIFO.

Solution: Check the level of the comports before accessing it. In the DMA case, you should use DMA synchronization.

Remember: Data in the Comm port's input FIFO's can only be read once. The debugger displays memory values by reading them from the 'C4x. It is best, therefore, to avoid displaying the input FIFO's in any of the debugger windows as this will cause the data to be unavailable to your program. In the example emuinit.cmd file shipped with the debugger the memory map commands that define the Comm ports' FIFO's are commented-out to avoid this problem but still show how they might be defined if you have need of them.

II) During execution of a large "Repeat Single" instruction.

The "repeat-single" instruction and the instruction that is being repeated is considered one single instruction from the emulator point of view. The emulator can only single-step between instruction fetches. In the case of the RPTS (C4x/C3x repeat single) , the instruction that is being repeated is fetched only once.

III) During interlocked instructions or during any instruction that accesses memory that is not ready

WARNING: Different debugger versions may present a different behavior.

For example, for the C4x XDS510, debugger versions 2.20 or higher will send a "processor access timeout addr=xxxx" message if a read or write access doesn't complete.
However debugger version 2.01 or lower may not send any warning message if a read access is broken. This "incomplete read" can be misinterpreted as an access completion.

THE ADDRESS PROVIDED IN THE ERROR MESSAGE:

The addr=xxxx provided in the message will "approximately" correspond to the address where the time-out occurs when this is the result of a "debugger" access time-out (for example from displaying memory). In the case of a CPU/DMA time-out, what you probably will receive is an address = 0xdeadc0de that is not meaningful. In this case the previous 3-4 instructions (in the case of a DSP with 4-deep pipeline) to the PC value should give you an indication as to where the time-out occurs.

WARNING: Sometimes a different message could be caused by the same problem.

Also, an "invalid operand" message coming from the debugger expression analyzer could be an indication that a timeout happens. (for example when you type "? *0xxxxxx" in the command window, where the address corresponds to a location that is timing-out.