• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 694 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.

SLOOP problem with interrupts using C6424 (Compiler can't solve)

Elric
Expert 1250 points
Hi, I am searching for a general optimization to the code since our project is running under the required time specifications. However, I have a problem with the SLOOPs which run unpredictable. We are using C6424 on our custom made board, and using Code Composer 3.3 in Windows to compile, no DSP/BIOS but our operating system. The optimization options are: Generate Debug Info: No Debug Opt Speed vs Size: Speed Most Critical (no -ms) Opt Level: File (-o3) Program Level Opt: No Ext Fun/Var Refs (-pm -op2) There is a known problem to back to back SLOOPs in errata, and the compiler is supposed to correct them. When I look to the compile generated assembly file, I only see one SLOOP is corrected by the compiler (there is the comment SDSCM00012367 HW bug workaround), and only a few SLOOPs are protected by compile added DINT and RINT. Besides that, the other unprotected SLOOPs (there are many of them) causes unexpected problems if an interrupt occurs while they are executing. I do not know how the interrupts interact with the SLOOPs and cause problem, but it makes continuous CPU stalling or making a jump to non-code area in the program flow. The most often case was in the usage of the stdio.h and string.h library functions, which have many SLOOPs. (actually I am not sure if the problem occurs with the non library SLOOPs, though string SLOOPs are being executed in large scales compared to the others in the program) To prevent the problem, I had to use CSL macros for clearing interrupts and restoring interrupts for every SLOOP. So every SLOOP in the code is now encapsulated with clear interrupts macro at the beginning and with restore interrupts macro at the end. Since we have minimal time requirements and time critical interrupts, this is being a heavy burden on the program. Now I am asking for help to understand what is the real cause of this SLOOP problem and if there is a way any other than encapsulating every SLOOP in the code. I will be appreciated for any help or advices. Erman
  • 0
    TI__Guru*** 125430 points

    What compiler version are you using?  I recommend updating to the latest (currently 6.1.13) as described here.

    If you have a need for reduced interrupt latency then you should be using the --interrupt_threshold compiler option as described in the compiler guide.  Keep in mind that will only apply to code you are compiling (i.e. libraries like RTS library should be recompiled with that option).

  • 0 in reply to Brad Griffis
    Expert 1250 points

    I am using Code Composer Studio 3.3, when I look from the help menu I see the Code Generation Tools version as v6.0.8. I will try updating it.

    The current interrupt threshold is 5000. Do you recommend to reduce the interrupt threshold value?

  • 0 in reply to Elric
    TI__Guru*** 125430 points

    Definitely update the compiler as that is a really old version.  The interrupt threshold is up to you.  You need to determine how much latency is acceptable for your application.

  • 0 in reply to Brad Griffis
    TI__Guru* 84110 points

    Elric,

    Can you show an example of assembly output code from your program where the v6.0.8 compiler did not adequately address the Advisory 1.3.4 "Back-to-Back SPLOOPs" errata? As long as the work-around is applied to any SPLOOP pairs that are too close, there should not be a problem with interrupts affecting the functionality of any of the SPLOOPs.

    It is much less common now to require the DINT/EINT wrapper with the SPLOOP construct than it was with the older Software Pipelining technique. In fact, I would expect the only reason to use the DINT/EINT wrapper should be for a critical loop where speed is more important than the resulting interrupt latency.

  • 0 in reply to RandyP
    Expert 1250 points

    RandyP,

    I suspect the problem may be valid for only the library functions such as sprintf. Using the library functions like sprintf lead to CPU stalling. But in case, we just encapsulated every SLOOP with clear and restore interrupts which may be a very very wrong idea. There is no output code for sprintf, it is just stated as a SLOOP in the assembly output file. 

    As I said we were using an old version of compiler. I updated the compiler but couldn't investigate the matter because of other issues. I will look to this and report the new situation here.