• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 1560 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.

Compiler/OMAP-L138: SPLOOP interruption issue with CGT 7.4.13

Rahul Prabhu
Guru** 116770 points
Part Number: OMAP-L138


Tool/software: TI C/C++ Compiler

We are supporting a customer who is reporting that they are running into a reset issue on their device and based on the data that they have captured , it seem like related to DSP SPLOOP instruction been interrupted.

we would like to check if this is a known issue and what is the correct way to avoid this issue. The code i question is legacy code which was previously compiled with older version of CGT where this was not observed. It is not clear why it occurs now,and if there is any relation to new compiler (v7.4.13)  but we would like to confirm as there was a previous issue where something similar was reported with SPLOOP:

 

Here are the symptoms and reading from the C674x DSP:

EFR  = 0x40000000

NRP  = 0xc7975fba

NTSR = 0x0001420f

IERR = 0x00000000

 

check with DSP core 674 document, it show

1. EFR show EXF flag =1, exception has been detected.

2. IERR show it's not internal exception.

3. NTSR bit 14:SPLX state issue happen due to SPLOOP been interrupted

Questions:

1. Compiler documentation indicates:

SPLOOPs that are terminated by an exception cannot be resumed correctly. The SPLX bit in NTSR should be verified to be 0 before returning. seem like the customer is facing the same issue as they can't resume correctly. So, is there a way to avoid this scenario? will HW or compiler insert mask interrupt during SPLOOP instruction?

2. section 7.13.1 Interrupting the Loop Buffer, states that  "Interrupts are automatically disabled 2 cycles before an SPLOOP(D/W) instruction is encountered. Does this mean HW will actually mask interrupts during processing SPLOOP? if yes then why are they seeing the SPLOOP interrupted issue? Is there a compiler setting that allows SPLOOP from not being interrupted or any other configuration missing?

3.  SInce the issue was not encountered before, with this legacy code base, they suspect this to be an  issue introduced because of the new compiler (v7.4.13)? It would be good to know from compiler champs if  they need to add any compiler option to avoid or prevent this issue? They use compiler option -im100, does it help avoid this issue?

Thanks for your help.

Regards,

Rahul

  • 0
    TI__Expert 3455 points

    A recent version of the 7.4 compiler has worked around a hardware related issue with SPLOOP and interrupts.  You might want to give that a try. 7.4.13 is an older version of the 7.4 compiler. The current version (as of 2017/05) is 7.4.21.

    software-dl.ti.com/.../download.htm

    But if the exception is not an internal exception as you state, then I don't know what is going on. It may not be an SPLOOP-related hardware issue.

    If an exception occurs in an SPLOOP, it can not be resumed.

    Interrupts will be temporarily disabled by the hardware while piping up an SPLOOP.  Once the loop reaches the steady-state, interrupts will be turned back on.  If an interrupts occurs, the iterations that are currently executing pipe down and the interrupt is serviced. Once the interrupt returns, the loop pipes back up from where it left off. Also once reaching the draining state, interrupts are temporarily turned off until the epilog of the loop has finished.

    -mi<n> only affects loops not able to be interrupted.  It tells the compiler how many cycles interrupts can be off.  This primarily affects software pipelined loops that do not use SPLOOP.  Please see the compiler user's guide for a description of multiple assignment code and the -mi option.  Because SPLOOP can be interrupted, -mi<n> does not affect the generation of SPLOOP code sequences.

  • 0 in reply to Todd Hahn
    TI__Expert 3455 points
    In case all else fails: Hammer: --disable:sploop will turn off use of SPLOOP in software pipelining, but still allow software pipelining. Wrecking ball: --disable_software_pipeline will turn off software pipelining.
  • 0 in reply to Todd Hahn
    TI__Guru** 116770 points
    Thanks for the insight and recommendations Todd. We will work with the customer to update the compiler version and let you know if this resolves the issue. Until then I have marked your response as a Suggested Answer :)

    Regards,
    Rahul