Other Parts Discussed in Thread: CCSTUDIO
any idea what caused this:

CCS was sitting at a breakpoint, the DSP was stopped, when the error occured. I'm using a XDS510USB emulator with CCS5.1.0.09000 running in Linux.
Lee
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.
Other Parts Discussed in Thread: CCSTUDIO
any idea what caused this:

CCS was sitting at a breakpoint, the DSP was stopped, when the error occured. I'm using a XDS510USB emulator with CCS5.1.0.09000 running in Linux.
Lee
Lee,
I haven't seen this issue here, therefore I can only give a few tips:
Does this happen constantly or only at random times? I always wonder if a glitch on the hardware or some sort of timeout may have happene.
Another idea is that, if you are debugging a DSP code that was started from the A8 side (via DSP/Link, Codec Engine, etc.), make sure no timeouts exist on the ARM side that could be resetting the DSP (I did this a number of times in the past when doing this mixed debugging).
From the same perspective, can you check if the power saving features of the device are disabled? This would be an issue if LInux is running on the A8 while you are trying to debug the DSP side.
Regards,
Rafael
desouza said:Does this happen constantly or only at random times?
The error has happened twice so far, each time under the same conditions.
desouza said:Another idea is that, if you are debugging a DSP code that was started from the A8 side (via DSP/Link, Codec Engine, etc.), make sure no timeouts exist on the ARM side that could be resetting the DSP (I did this a number of times in the past when doing this mixed debugging).
From the same perspective, can you check if the power saving features of the device are disabled? This would be an issue if LInux is running on the A8 while you are trying to debug the DSP side.
I'm using Syslink on a C6A8168. How do I check for timeouts and power saving on the ARM? By the way, my code on the DSP, from a random location and at a random time, goes into the weeds. Frequenctly when this happens CCS hangs. Could a non-deterministic bug like this be caused by one of the conditions that you mentioned? My app is independent of all the other things that are running on the EVM, some of which also use Syslink, could something else be stepping on my code?
Lee
Lee,
Regarding the timeouts, I mentioned that since once I had an ARM-side app that had a forever loop to allow debugging my DSP-side app, but I forgot to disable a "watchdog" process I created that killed my app after X minutes. However this was my own wrongdoing as DSP/Link (and I guess Syslink) does not have any inherent timers.
The low power mode would be something built into the Linux kernel. I think the default configuration for the DM816x devices does not have this enabled, but I may be wrong. In any case you can always rebuild your kernel or verify its configurations.
The fact the DSP code hangs at random locations indicates that the origin of the issue is something asynchronous to the code execution: a timer, an exception, an invalid reset issued by either a watchdog or an external device or even a HW failure. The fact that CCS hangs indicates it is attempting to communicate with the hardware without success, and I understand this is a very undesirable scenario (it should have some sort of timeout).
You could potentially rule out any reset caused by watchdogs if you are able to kill CCS, restart it and still connect to the A8 (you may have to kill ccstudio.exe and possibly a few other processes like TraceCntrl.exe, TraceCompMgr.exe or TraceServer.exe in the Task Manager).
I will try to think of other ideas that may help you further debug this.
Regards,
Rafael