Concerto DSP (c28) hangs at FXN_N_selfLoop() - intermittent problem

Hi Pat,

I'm not sure if there's any documentation on that function.  Actually, any chance that you saw "FXN_F_selfLoop" and not "FXN_N_selfLoop" (note "N")?

The reason I ask is when I sift through the BIOS code, I can't seem to find FXN_N_selfLoop anywhere; however I do see "FXN_F_selfLoop".

"FXN_F_selfLoop" looks to be the same as "HWI_unused", which is the default ISR to run for a HWI.

Is your app using the HWI dispatcher?  If so, is it possible that you have mapped an interrupt to a HWI instance, but have not changed the ISR from the default (of HWI_unused)?

If so, it could be that some interrupt is triggering, and the HWI dispatcher is trying to handle it, but since there is no function (ISR) configured for that particular HWI, then it vectors to the default ISR, FXN_F_selfLoop.

Steve

Steve,

Thanks for your reply. I am not familiar with the HWI dispatcher. I am somewhat in the dark here as most of the C28 code was developed by Ti for the G3 power line control function. In the flash_init.c file developed by Liang and Yim, I see the following:

/*****************************************************************************
* FILE PURPOSE: Header file for init flash
*******************************************************************************
*
* FILE NAME: flash_init.c
*
* DESCRIPTION:
* Header file for flash
*
* Copyright (c) 2004 Texas Instruments Inc.
* All Rights Reserved This program is the confidential and proprietary
* product of Texas Instruments Inc. Any Unauthorized use, reproduction or
* transfer of this program is strictly prohibited.
*
* HISTORY:
*
* 04/15/2009 R.Liang initial version
* 06/10/2009 S.Yim Added ram section for viterbi and fft
*
******************************************************************************/
#include "DSP28x_Project.h"
#ifdef F2806X
#include "F2806x_Device.h"
#elif defined (F28M35X)
#include "F28M35x_Device.h"
#else
#include "DSP2833x_Device.h"
#endif

#include <string.h>

// Used for running BackGround in flash, and ISR in RAM
extern Uint16 secureRamFuncs_loadstart;
extern Uint16 secureRamFuncs_loadend;
extern Uint16 secureRamFuncs_runstart;

extern Uint16 phyRamFuncs_loadstart;
extern Uint16 phyRamFuncs_loadend;
extern Uint16 phyRamFuncs_runstart;

extern Uint16 hwi_vec_runstart;
extern Uint16 hwi_vec_loadstart;
extern Uint16 hwi_vec_loadend;

extern Uint16 trcdata_runstart;
extern Uint16 trcdata_loadstart;
extern Uint16 trcdata_loadend;

/**********************************************************************
* Function: config_flash()
*
* Description: Initializes and enables the PIE interrupts on the F280x.
**********************************************************************/
void config_flash(void)
{
// Copy time critical code and Flash setup code to RAM
// The RamfuncsLoadStart, RamfuncsLoadEnd, and RamfuncsRunStart
// symbols are created by the linker. Refer to the linker files.
memcpy(&secureRamFuncs_runstart,
&secureRamFuncs_loadstart,
&secureRamFuncs_loadend - &secureRamFuncs_loadstart);

#if 1
memcpy(&phyRamFuncs_runstart,
&phyRamFuncs_loadstart,
&phyRamFuncs_loadend - &phyRamFuncs_loadstart);

#endif

// Call Flash Initialization to setup flash waitstates
// This function must reside in RAM
// InitFlash code in CSL.lib
InitFlash(); // Call the flash wrapper init function
}

/**********************************************************************
* Function: InitPieVector()
*
* Description: Initializes and enables the PIE interrupts on the F280x.
**********************************************************************/
void InitPieVector(void)
{
//--- Disable interrupts
asm(" SETC INTM, DBGM"); // Disable global interrupts

//--- Initialize the PIE_RAM
PieCtrlRegs.PIECTRL.bit.ENPIE = 0; // Disable the PIE
asm(" EALLOW"); // Enable EALLOW protected register access

memcpy(&hwi_vec_runstart, &hwi_vec_loadstart,
&hwi_vec_loadend - &hwi_vec_loadstart);

asm(" EDIS"); // Disable EALLOW protected register access

#if 1
//--- Disable all PIE interrupts
PieCtrlRegs.PIEIER1.all = 0x0000;
PieCtrlRegs.PIEIER2.all = 0x0000;
PieCtrlRegs.PIEIER3.all = 0x0000;
PieCtrlRegs.PIEIER4.all = 0x0000;
PieCtrlRegs.PIEIER5.all = 0x0000;
PieCtrlRegs.PIEIER6.all = 0x0000;
PieCtrlRegs.PIEIER7.all = 0x0000;
PieCtrlRegs.PIEIER8.all = 0x0000;
PieCtrlRegs.PIEIER9.all = 0x0000;
PieCtrlRegs.PIEIER10.all = 0x0000;
PieCtrlRegs.PIEIER11.all = 0x0000;
PieCtrlRegs.PIEIER12.all = 0x0000;

//--- Clear any potentially pending PIEIFR flags
PieCtrlRegs.PIEIFR1.all = 0x0000;
PieCtrlRegs.PIEIFR2.all = 0x0000;
PieCtrlRegs.PIEIFR3.all = 0x0000;
PieCtrlRegs.PIEIFR4.all = 0x0000;
PieCtrlRegs.PIEIFR5.all = 0x0000;
PieCtrlRegs.PIEIFR6.all = 0x0000;
PieCtrlRegs.PIEIFR7.all = 0x0000;
PieCtrlRegs.PIEIFR8.all = 0x0000;
PieCtrlRegs.PIEIFR9.all = 0x0000;
PieCtrlRegs.PIEIFR10.all = 0x0000;
PieCtrlRegs.PIEIFR11.all = 0x0000;
PieCtrlRegs.PIEIFR12.all = 0x0000;

//--- Acknowlege all PIE interrupt groups
PieCtrlRegs.PIEACK.all = 0xFFFF;

//--- Enable the PIE
PieCtrlRegs.PIECTRL.bit.ENPIE = 1; // Enable the PIE
#endif
} // end of InitPieCtrl()

/**********************************************************************
* Function: UserInit()
*
* Description: This is the user initialization file to be specified in
* the DSP/BIOS configuration file, System - Global Settings.
**********************************************************************/
void UserInit(void)
{
// Section .trcdata is generated by DSP/BIOS.
// It must be copied from its load to its run address BEFORE main().
memcpy(&trcdata_runstart, &trcdata_loadstart, &trcdata_loadend - &trcdata_loadstart);

} // end of UserInit()

void flash_setup(void)
{
//copy trcdata
// R.Liang:
// UserInit is called by main. It is hook function by DSP/BIOS
// don't call this function anymore, otherwise the GBL_Init_done
// is reset to zero.

//UserInit();

// copy Pievector
InitPieVector();

//config flash
config_flash();
}
//--- end of file -----------------------------------------------------

Do you see anything here that might cause a conflict?

When I halted the program during a hangup, I got the following:

Thanks,

Pat

Here are some more screens captured during the hang up:

3404.DSP_BIOS_screens3.docx

And yes, it was FXN_F_selfLoop(), sorry.

Pat,

What is it exactly that you are running?  Is it an example of some sort?

From what I can tell, it seems to be an application that runs on top of DSP/BIOS.  I think it may help to find out what that example is, which SDK it came from, etc.

If we can find that out, then I can try to get in contact with the team who developed that.

Steve

This project with the PLC example code provided by Wonsoo Kim and others. 

Here are the latest files I have from Wonsoo:

5773.8737.TI_PLC_G3_PHY_EXAMPLE.zip

I do not have very good documentation on the drivers nor any source code, so I somewhat in the dark as to what is happening and should be happening.

Thanks,

Pat

Ok.  I've sent an email to Wonsoo.  Hopefully he will be able to help, or at least help us find the right person to help!

Steve

Hi Pat,

We have PLC application-level document in user guide document (that I believe that we have already shared with you) but I don't have any documents specifying the causes of SELF-LOOP.

Based on the ROV, it seems that AIO_Task was running and I wonder if the task might cause some issues. Another thing you may need to check is the PC (program counter) and RPC (return program counter)  in core register tab in CCS. This might give you some clues of why this happens.

Regards,

Wonsoo

Hi Wonsoo,

Thanks for your reply. By restricting communication through the IPC, I was able to get satisfactory results.

I have a number of additional questions that I would like to dialog with you concerning the performance of the TI PLC network design and operation. We are now running a complete simulation using a network of 75 nodes that extend over 3/4 mile. We have seen considerable line loss and have had to make modifications to the original AFE  and coupling circuit that was recommended in the example.

I would like to discuss these changes and explain more about our application in hopes of finding a solution to our current problems with signal loss in our network.

Perhaps we could communicate more directly using email?

THanks,

Pat

Pat,

Sorry for late response. Yes, please contact me via wonsoo.kim@ti.com. We can discuss the performance issue via email.Thanks.

Wonsoo