Hello,
I am using a DM8148 custom board, and running on the C674x using EZSDK_5_03_01_15 components.
components:
- bios 6.32.05.54
- cgt6x_7_3_1
- c674x-dsplib_1_03_00_00
In my DSP application, I have a high priority and short GPIO HWI.
and three SWIs, with different priorities, running each the DSPF_sp_fftSPxSP kernel.
the application runs for a while and then the code abort() with a loop buffer exception that point inside the DSPF_sp_fftSPxSP function.
From my understanding, the FFT kernel use SPLOOP so It means it's interruptible.
I have increase drastically my program stack just in case nesting those interrupts could cause a stack overflow.
I do not understand what can cause a loop buffer ecxeption.
the compiler should backup/restore the loop buffer content from/into the stack, isn't it?
attached my project .cfg file and .map file.
5153.map and config files.rar
exception system_printf dump :
[C674X_0] A0=0xfffffff4 A1=0xfffffffa[C674X_0] A2=0x2 A3=0xbd08eec1[C674X_0] A4=0xbbcbc1ec A5=0x942afda0[C674X_0] A6=0x3c8a296e A7=0x3c488329[C674X_0] A8=0xbc130142 A9=0xbbf71dae[C674X_0] A10=0xbcca3258 A11=0xbc9a7b3e[C674X_0] A12=0xbc153b72 A13=0x3d139de2[C674X_0] A14=0x18 A15=0xa46fa1d2[C674X_0] A16=0xbc58aa04 A17=0xbbe0b4eb[C674X_0] A18=0xbf3504f3 A19=0xa3830474[C674X_0] A20=0x3c5e3522 A21=0x3bf1b9a2[C674X_0] A22=0xbc95049c A23=0xbb44b5d4[C674X_0] A24=0x3f3504f3 A25=0x3f3504f3[C674X_0] A26=0x18 A27=0x942afd10[C674X_0] A28=0x16 A29=0x8[C674X_0] A30=0x9429a880 A31=0x9429a7f0[C674X_0] B0=0x3f0e39da B1=0x3f54db31[C674X_0] B2=0x8 B3=0x16[C674X_0] B4=0xbc09e63c B5=0xbcc51402[C674X_0] B6=0x3b05921e B7=0x3c065a70[C674X_0] B8=0xbc296d40 B9=0x3cb66404[C674X_0] B10=0x3cf28032 B11=0x3b109372[C674X_0] B12=0xc0 B13=0x7e0[C674X_0] B14=0x942d3788 B15=0x9524fe70[C674X_0] B16=0x9429a8c8 B17=0x3b9f4696[C674X_0] B18=0x942afda0 B19=0x8[C674X_0] B20=0x3d87c50c B21=0xbbd5f90b[C674X_0] B22=0xbd925cb6 B23=0x3b9cee52[C674X_0] B24=0xbf7b14be B25=0x3e47c5c2[C674X_0] B26=0x3cba7581 B27=0x3c444886[C674X_0] B28=0x3bacadac B29=0x3c970ca9[C674X_0] B30=0xbcb2f485 B31=0x3a092540[C674X_0] NTSR=0x1420f[C674X_0] ITSR=0x420f[C674X_0] IRP=0x9526978c[C674X_0] SSR=0x0[C674X_0] AMR=0x0[C674X_0] RILC=0x40[C674X_0] ILC=0x24[C674X_0] Exception at 0x95269954[C674X_0] EFR=0x2 NRP=0x95269954[C674X_0] Internal exception: IERR=0x90[C674X_0] Resource conflict exception[C674X_0] Loop buffer exception[C674X_0] ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x9526978c, sp = 0x9524fe70.[C674X_0] xdc.runtime.Error.raise: terminating execution
Please confirm the version number of DSPLIB. Because it is much more likely that you have dsplib_c674x_3_1_0_0 from here.
Thanks and regards,
-George
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
Because of technical difficulties with the forum yesterday, Mr. Journo did not respond online, but by private message. He did confirm that he is using dsplib version 1.03.00.00. And to directly answer a side question ... Yes, the dsplib routines are presumed to be re-entrant.
I did determine that the current revision of dsplib (v3.1.0.0) has the same implementation of this function. And that implementation is in hand-coded assembly. So, upgrading would not help. The dsplib team is aware of this issue, and they are taking a closer look. I think we have everything we need, for now.
Hello George,
I'd like to know how to follow the issue.
Is there a way for me to know what is the status of the research/analyze of the specific fft kernel?
using the natural C fft function is quite lower and it harms the overall performance of our application.
We're really waiting for a fastest solution than the natural C function.
Thanks for your comprehension,
Jonathan.
Hi Jonathan,
I am in charge of DSPLIB development. I verified that the exception does not occur in our unit test environment. It maybe related to interrupts. The exception happened in the middle of a SPLOOP. Interrupt return address points to the start of the same SPLOOP, which means interrupt should have happened during the loop. I wonder if you can turn off the interrupt and see if you still get the exception?
regards,
Yimin
Hi Yimin,
For your question, I am working with a GPIO interrupt for sampling task. The GPIO event interrupt is handled using the HWI dispatcher so I hope the bios does its registers/stack save/recovery correctly. I am not using isr directly.
I can't disable that interrupt because it is responsible to synchronize and trigger the other 3 SWI threads where the FFT is running in each of them.
Instead of the GPIO interrupt, I have tried to connect a dm timer interrupt instead and the exception still occurs.
We are still working on the issue. In the unit test, we added timer interrupt to try to catch the exception. So far, it has not happened. I will keep you updated of any progress.