• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 647 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CPU Exception: Internal: Loop buffer exception; Missed stall exception;

CCS: Loop buffer exception - missed stall. An unexpected solution

Domenico Logozzo
Prodigy 160 points

Tool/software: Code Composer Studio

Hello experts,

I'm still using Code Composer version 3.3.82.13 with a DSPBIOS application with a c6457 processor. I was trying to reproduce a bug that was reported by a colleague of mine on the unit equipped with the board which hosts the c6457 DSP.

To achieve in reproducing that I was using DSPBIOS (version 5.33.06) message logs and my emulator connected to jtag. Unfortunately when I used those then the application aborted after few seconds because an internal exception was thrown: "Loop buffer exception and missed stall". I did many attempts to try not to generate the exception. Message log was the only way I could hope to debug my code but when I tried to use those I always obtain the same error (not the one I was searching to reproduce). No way to obtain that strange exception if I didn't use the emulator connected to the board.

Finally, just as the last attempt, I have tried to run my application in real-time mode. That eliminates the above problem definitely! How is it possible? I thought that this modality only had to do with the ability to break programs and let the interrupt being serviced at the same time. Do you have some kind of technical answer explaining this unexpected behavior?

  • 0
    TI__Guru** 116170 points

    I am looping in our CCS experts to comment but a quick search on the E2E lead me to the following two posts that had a similar issue reported that was showing this issue due to SPLOOP in the code under debug:

    https://e2e.ti.com/support/processors/f/791/t/85262?Loop-buffer-exception-and-Missed-Stall

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 160 points

    Hi Rahul,

    I have read those posts too. Indeed I didn't ask the cause of the exception. I was asking why using emulator it comes up and why if you run the application in "real-time mode", which is a modality you can find in the "Debug" menu of CCS IDE, the problem disappears.

    Regards

  • 0 in reply to Domenico Logozzo
    TI__Guru**** 171004 points

    Hi,

    Please apologize for the delay.

    As you can imagine from the linked thread you referenced above, the core issue itself is very elusive.

    The missed stall is a runtime issue also covered by me in this other thread:

    https://e2e.ti.com/support/processors/f/791/p/85262/294226#294226

    Although the JTAG is designed to perform complete access to the target core/device, it does not guarantee the access is unobtrusive - just take a memory or register read, for example, that requires the core to be halted. 

    It is no different when the core is put to run - depending on the device, minimal interactions between the core and the host are bound to happen, so that a minimal monitoring about the target status is maintained. The Real-time mode is one approach to minimize this interference by disabling the monitoring and control of interrupts of the device. Another is "Free Run", which disables all monitoring and allows performing power transitions and other sleep iterations.

    A borderline condition on the combination of code and device may be triggering this missed stall. Unfortunately one would need a full core trace to precisely track this issue. 

    As a last attempt is to see if anything on the compiler/optimizer itself may be triggering this. By downloading a newer version of the compiler, you can try to see if a bug or implementation issue was fixed. Unfortunately I don't think that our current download page goes that far back to CCSv3.3 days. Also, keep in mind that, by fixing this issue, the optimizer may act more conservatively and thus translate into a slower code.

    Regards,

    Rafael