Loop buffer Exception inside DSPF_sp_fftSPxSP

An update,

the same code using the natural C code DSPF_sp_fftSPxSP_cn.c is working OK.

Might the asm kernel be buggy?

Not that I'm offering solution, but I wonder if you can confirm following. Provided your map file and disassembler output for DSPF_sp_fftSPxSP.obj from dsplib674x_elf.lib failing instruction is STDW.D2T2 B7:B6,*B16++[B19], two lines above SPKERNEL 0,11. Can you confirm that this is indeed the case? To do that 'dis6x your_binary.out > file.txt', open file.txt in text editor and locate 95269954, the failing address. Is it above mentioned STDW instruction in vicinity of above mentioned SPKERNEL?

For reference, DSPF_sp_fftSPxSP appears/is interruptible, but it has lesser to do with SPLOOP, in sense that one can program SPLOOP in such way that it would require disabled interrupts to operate correctly. Nor does interrupting SPLOOP work by saving loop buffer content on stack, but it's of lesser relevance...

Because I compile a new version of my project, the exception address moved "a bit" but is consistent.

new exception dump:

[C674X_0] A0=0xffffffbe A1=0xffffffc4
[C674X_0] A2=0x4 A3=0x0
[C674X_0] A4=0xbdfde7d3 A5=0x9448ee50
[C674X_0] A6=0x3ef5ba19 A7=0x0
[C674X_0] A8=0x3ff90da8 A9=0x0
[C674X_0] A10=0x3e703bda A11=0x3bc75643
[C674X_0] A12=0x3de3cce8 A13=0x3e703bda
[C674X_0] A14=0x8a A15=0x80000000
[C674X_0] A16=0x3f0099cc A17=0x0
[C674X_0] A18=0xbf7fb10f A19=0xbd738612
[C674X_0] A20=0x3ebbdda2 A21=0x0
[C674X_0] A22=0x3ed2d09e A23=0x0
[C674X_0] A24=0x3f039c3d A25=0x3f5b941a
[C674X_0] A26=0xc0 A27=0x9448ea30
[C674X_0] A28=0xbe A29=0x40
[C674X_0] A30=0x9447bd30 A31=0x9447b760
[C674X_0] B0=0x3efc5d27 B1=0x3f5ebe05
[C674X_0] B2=0x40 B3=0xbe
[C674X_0] B4=0xbccf48e6 B5=0xbe0b676c
[C674X_0] B6=0x0 B7=0xbd0b2576
[C674X_0] B8=0xbdd2b158 B9=0x3dd2b158
[C674X_0] B10=0x3c71fd20 B11=0x0
[C674X_0] B12=0x600 B13=0xf00
[C674X_0] B14=0x94a57b00 B15=0x94a50fc0
[C674X_0] B16=0x9447bbb8 B17=0xbe0b676c
[C674X_0] B18=0x9448ee50 B19=0x40
[C674X_0] B20=0x3fe199c4 B21=0x0
[C674X_0] B22=0xbcc9ddef B23=0x0
[C674X_0] B24=0xbf7fec43 B25=0xbcc90ab0
[C674X_0] B26=0x3ed689be B27=0x0
[C674X_0] B28=0x3f131ff8 B29=0x0
[C674X_0] B30=0x3efa4df8 B31=0x0
[C674X_0] NTSR=0x1420f
[C674X_0] ITSR=0x420f
[C674X_0] IRP=0x94a19b0c
[C674X_0] SSR=0x0
[C674X_0] AMR=0x0
[C674X_0] RILC=0x80
[C674X_0] ILC=0x69
[C674X_0] Exception at 0x94a19cd4
[C674X_0] EFR=0x2 NRP=0x94a19cd4
[C674X_0] Internal exception: IERR=0x90
[C674X_0] Resource conflict exception
[C674X_0] Loop buffer exception

ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x94a19b0c, sp = 0x94a50fc0.
[C674X_0] xdc.runtime.Error.raise: terminating execution

NRP=0x94a19cd4 address point to the same instruction into the ASM routine.

Uhm... All instructions appear identical except for one, SPKERNEL. My copy of DSPLIB 1.03 has SPKERNEL 0,11, while you show 4,3... I've even checked most recent version 3.1, it's same code there, same source, same binary. For corresponding SPLOOP instruction found in my copy 4,3 would actually be inappropriate/invalid value. What's your SPLOOP? Slide up in disassembly till you see SPLOOP, it should be at 0x94a19b0c. I have SPLOOPD 14, what do you see?

Anyway, if we assume that your disassembler simply renders SPKERNEL instruction wrong (for whatever reason), it's very strange place to suffer from resource conflict. ILC value suggests that the loop actually executed a fair number of iterations, meaning that it generally works. IRP value suggests that loop was interrupted earlier, but recovering from interrupt is equivalent to initial stage, which is also generally works, since loop did start at least once and progressed to given ILC...

P.S. Just for the record, my interest in this is following. I've recently implemented a number of hand-coded SPOOP-based subroutines and am interested to figure out if my code can suffer from something similar.

effectively, as you said, the DSP code run for a while and then crash. (I could not restore a crash specific sequence. Maybe it occurs at a very specific timing because of interrupts).

Unfortunately, after another exception, I tried to read the the SPKERNEL/SPLOOP instruction but then it was the expected SPKERNEL instruction: SPKERNEL 0,11.

Should I try to recompile the library?

Jonathan Journo said:

Unfortunately, after another exception, I tried to read the the SPKERNEL/SPLOOP instruction but then it was the expected SPKERNEL instruction: SPKERNEL 0,11.

As implied it's not impossible that disassembler simply displayed it incorrectly. Basically in order to disassemble SPKERNEL correctly one has to look at corresponding SPLOOP parameter. If disassembler didn't care to look back "far enough" it could have assumed some most common parameter and as result displayed SPKERNEL parameters incorrectly. I just had second closer look and it's the same encoded instruction as I have,  0x02C34001. So that 4,3 vs 0,11 must be simply disassembler glitch, nothing to worry about. Sorry about confusion.

Jonathan Journo said:

Should I try to recompile the library?

With above in mind there is no reason to do that. What I can offer is slightly modified subroutine with no STDW pairs. I mean if we assume that STDW pairs is culprit [for whatever reason], then breaking pairs should make it work. Unfortunately I won't be able to verify the modified code, as I don't have C67x processor. You'll have to do it. The SPLOOP-based code of mine I mentioned earlier is developed on C64x+,  but it shall work even on C67x.

OK,

I'll be happy to try your modified asm kernel.

Did you find the solution to your problem?  I'm very interested in your post because I'm currently working on a very similar problem.  I've narrowed my search down to a  routine that I've optimized.  I experience an exception much like you (see below).  If I reduce the optimization below -o2 (where no SPLOOP's are used) everything works fine.  So I'm looking into this area now.  

[C674X_0] A0=0x1 A1=0x0

[C674X_0] A2=0x0 A3=0x11827884

[C674X_0] A4=0x0 A5=0x10b20800

[C674X_0] A6=0x0 A7=0x16e36000

[C674X_0] A8=0x0 A9=0x1181ba18

[C674X_0] A10=0x14000100 A11=0x118277cc

[C674X_0] A12=0x0 A13=0x0

[C674X_0] A14=0x0 A15=0x0

[C674X_0] A16=0x302e3030 A17=0x0

[C674X_0] A18=0x11824fa0 A19=0x40

[C674X_0] A20=0x1181aaa0 A21=0x0

[C674X_0] A22=0xc1f17bc9 A23=0x0

[C674X_0] A24=0xa34b5d17 A25=0xfa367fe5

[C674X_0] A26=0x1c14164 A27=0x1c14164

[C674X_0] A28=0x1c14160 A29=0x1c14160

[C674X_0] A30=0x20 A31=0x0

[C674X_0] B0=0x1 B1=0x0

[C674X_0] B2=0x0 B3=0xc

[C674X_0] B4=0x11827ae4 B5=0xbe

[C674X_0] B6=0x79 B7=0x3ccdf

[C674X_0] B8=0x0 B9=0x11827990

[C674X_0] B10=0x1 B11=0x118277c8

[C674X_0] B12=0x0 B13=0x0

[C674X_0] B14=0x11829ee8 B15=0x1181fc48

[C674X_0] B16=0xbebebebe B17=0xbebebebe

[C674X_0] B18=0xa B19=0x78

[C674X_0] B20=0x69 B21=0x3588fad4

[C674X_0] B22=0x20f B23=0x0

[C674X_0] B24=0xd0893a65 B25=0xe7d21ef9

[C674X_0] B26=0x4a118285 B27=0xf784eb9f

[C674X_0] B28=0xbd98d524 B29=0x11f03dc0

[C674X_0] B30=0x11f03dc0 B31=0x0

[C674X_0] NTSR=0x1000f

[C674X_0] ITSR=0xf

[C674X_0] IRP=0x118133e0

[C674X_0] SSR=0x0

[C674X_0] AMR=0x0

[C674X_0] RILC=0x0

[C674X_0] ILC=0x0

[C674X_0] Exception at 0xc

[C674X_0] EFR=0x2 NRP=0xc

[C674X_0] Internal exception: IERR=0x1

[C674X_0] Instruction fetch exception

[C674X_0] ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x118133e0, sp = 0x1181fc48.

[C674X_0] To see more exception detail, use ROV or set 'ti.sysbios.family.c64p.Exception.enablePrint = true;'

[C674X_0] xdc.runtime.Error.raise: terminating execution

Hi David,

I have not found a solution because I haven't the time to debug/investigate the TI library. I am working for now with the a C code fft.

regarding your exception:

it seems it is not a loop buffer exception but an instruction fetch exception.

also the NRP is 0xc, wich is the last instruction address that the CPU have executed.

0xc is not a valid address , your code section migth be at a higher addresses .

so I would suspect a memory crash/overwrite on your code section , or a non valid pointer.

0523.DSPF_sp_fftSPxSP.asm

What's different is that store instructions that was causing resource conflict exception are not paired anymore. Once again, I don't have the CPU, I can only verify that it compiles, but not that it works correctly...