Problem: CPU STALL

Elric said:

The problem is, when the program is running heavily (for example reading data from DDR2 or L2 ram and giving it to uart continously), it has a life time of about 8-9 minutes. Then the execution stops and when I want to check with the emulator, I have the common message of CC Studio about the "CPU STALL".

I am not sure I have come across this particular message, could you post a screen shot of the error box? To debug deeper into what this means it may be worth checking where the program counter ends up assuming the error is not a fatal emulation error.

As to avoiding an intermittent load related problem like this, the first thing I would try as an attempt at a quick fix would be to update to the latest tool versions, primarly the CGT and BIOS versions, to see if that impacts the behavior and to try ruling out a tool related bug that has already been fixed.

The error box is on the upper entry. I don't think this particular case is related to a tool version or an emulation error. The pipeline stalling began with the new timer configuration (leading to much more execution burden to the program, but is a certain necessity also). Another thing is, execution stops (stalling or a deadlock occurs) before I connect with the emulator. I can see  that via a terminal program (Teraterm) ince the program gives data to the uart continuously.

So far (with the help of the errata), I tried the asm6x application with the main .asm file since there is a known possible problem with Sloops and interrupts together. Also I tried configuring the L2 as full cache to see if the stalling occurs because of an IDMA/SDMA accessing. Neither were the case and the cpu stalling continued to happen still.

You are right that though this is an error given by the emulator that it is probably not an emulation problem, this means that the CPU itself is actually stuck in a stalled state which appears to be valid but should not happen so indefinitely. As the error suggests this indicates that the CPU tried to access something that it could never get to, for example if you were fetching code or data from the asynchronous interface on the EMIF and for some reason the wait signal got stuck asserted indefinitely, or perhaps more likely if you were fetching code or data from some invalid location in the memory map that happens to never return.

I would say that this could still be a tool issue, if there is some bug in the code generation tools that leads to the CPU to try to access an invalid location it could cause this sort of problem, though I agree this is less likely due to the relationship with the CPU loading, it is still a possibility. In general I try to rule out CGT issues first as that is the easiest step to take, otherwise in a case like this we are looking at some potentially ugly debugging.

In either case, when you hit yes to force the CPU ready is the program counter in a predictable location or does it appear random? Is the program counter in an expected place (i.e. within valid executable code)?

Hi Elric & Bernie ,

I am observing similar kind of issue while connecting to DM6446 EVM. ARM gets connected properly and while connecting to DSP, it gives following error message

I tried forcing CPU to ready(by clicking Yes) but i got the same message. Is there any problem with EVM or am I doing any thing wrong?

Can you please help me out in fixing this issue?

-Santhosh Gunna

Usually you would see a different error relating to being held in reset for most typical DSP connection problems on the DM6446, like seen in this thread, however to see a CPU stalled error like this on boot up is a bit unusual. The first area I would check is your boot mode, perhaps trying another boot mode (one that does not boot anything, like UART boot), as my suspicion would be that your DSP is ending up running something inadvertently that is locking it up. You may also try holding the device in reset until just before you connect with CCS. When you power up your board is it still running U-Boot and than booting Linux?