how to debug the DSP/BIOS on c2000 platforms

Here are some pointers and typical scenarios when a BIOS application could end up in the FXN_F_selfLoop.

1) This kind of problem could occur because of the linker option –cr (Project->Build options->Linker->Basic->Autoinit Model->Load-time Initialization). Changing this option to –c (Run-time Autoinitialization) may help get rid of this issue. When -cr option is turned on, the global variables will be initialized only during load time. So when you do Debug->Restart(without loading), initialization is not performed and hence it could end up in FXN_F_selfloop.

2) Applications may also get to FXN_F_selfloop because of bad function pointers or stack overflow or because of global variable or stack corruptions at runtime.

3) More often, a reason why the control gets transferred to the FXN_F_selfLoop could be the following:

FXN_F_selfLoop is the default ISR for unplugged interrupts. It is done to catch any stray interrupts. In general, FXN_F_selfLoop function gets called if an interrupt gets triggered which does not have an ISR defined for it.

One approach to determine if this is happening is to check the IER/IFR register. The FXN_F_selfLoop is mostly hit because user has enabled such interrupts in the IER. The IER register should have only the interrupts required for the application. If any interrupt is enabled but that is mapped to the function HWI_unused, then it is possible that FXN_F_selfLoop could be hit.

There is another method to catch such an interrupt. User can place break points on all HWI_obj defaulted to the HWI_unused. The one which is calling the FXN_F_selflLoop will be hit and the HWI_obj can be found out. User can also define interrupt service routine for all the suspected interrupts and place breakpoints in those routines to determine which interrupt is getting triggered.

4) If there are NMI's in the system, on C28x DSP/BIOS does not support returning from an NMI interrupt when PIE is enabled and other interrupts are using the dispatcher. Doing so may result in the code ending up in FXN_F_selfLoop. More information on this can be found in the C28x DSP/BIOS 5.32 Application Programming Interface (API) Reference Guide, SPRU625, Pg 2-140.

Some other general DSP/BIOS Debugging tips that might also be helpful are at http://tiexpressdsp.com/wiki/index.php?title=DSP_BIOS_Debugging_Tips

hi

i found out the interrupt, it's HWI_ILLEGAL.  i don't know how to fix the problem

i also verified all others parameters.

i'm still stuck in KNL_Glue function due to HWI_ILLEGAL

how can i do ?????

I have the same problem. Can you provide some more details on how you fixed it?

I'm using CCS 3.1 for development with a F2812 microcontroller.

I've tried BSP 4.90 (comes with CCS 3.1) and I've tried BSP 5.20.04.33 (off the top of my head, it's the most recent BSP recommended for C28XX from the TI website for CCS 3.1).

How can I tell what version of cgt tools I am using? It seems like version 5.2.1 comes with CCS 3.3. Are you using CCS version 3.3? Also, what do the cgt tools contain? It seems like there must have been a compiler fix that corrected the issue.

Did you try an example without changes or did you modify the example? Which example was it? Maybe I can try it as well and see if I'm suffering from the exact same problem or not.

Is there a download for cgt tools 5.2.1on the TI website?

Note also: I've tried the other recommendations. According to CCS the stacks didn't overflow.

Interestingly, in my code, there's a HWI service routine for XINT1 that is calling MBX_post with timeout set to 0. If I comment out that one line then the crash doesn't occur (unfortunately, the application loses most of its functionality as a result!).

Many thanks!

Hello Aarti,

Can you take a look at the following post? I believe that I may be suffering from a system stack overflow but I'm not sure how I can detect that.

http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/32814/114309.aspx#114309

Thanks!

Greetings Aarti and DSP BIOS Champs!!

Thanks to your detailed post that I discovered here, I was able to resolve the issue that I recently had related to FXN_F_selfLoop. 

I was able to use the tips in this thread and the link to  DSP_BOIS_Debugging_Tips.  I was correctly lead to the Kernel Object Viewer tool

and was able to determine that there is a potential stack overflow problem due to the TSK_idle (Task Function: IDL_F_Loop).  The stack size

by default is set to 128 MAUs.  The KOV showed a peak usage of 127...I increased the size of the stack and that resolved the problem.

I was just wondering if there is an app note that describes a proper method to select the stack size?  Generally I think this is just a guesstimate, however, since it is a common problem I wonder if the BIOS team has created some guidelines...that would be quite helpful.

Thanks again!

Krishna Allam

 PS.  It is nice to communicate with you after a long time!