SW v1.10.01.01 USB Initialization problem

Mike,

This indicates that you are encountering an interrupt that has not been assigned its own custom ISR.  There are a few ways this could happen:

1. An interrupt has been enabled but not registered to an application-provided ISR
2. An NMI event occurs

I think #1 is more likely, but if you follow the interrupt setup procedure used by the example applications then you shouldn't have any trouble.  Case #2 can occur with some of the older C6748 SOMs due to an errata item (especially if you are using the touch screen in your application).

Hope this helps.

Joe,

Joe Coombs said:

This indicates that you are encountering an interrupt that has not been assigned its own custom ISR. 

I actually traced the problem to delay()  called by USBDCDCInit(). There is a an infinite loop sysdelay() that never recieves its interrup.

void Sysdelay(unsigned int ulTime)

{

TimerPeriodSet(SOC_TMR_0_REGS, TMR_TIMER12, (ulTime * TMR_PERIOD_LSB32));

 

/* Start the timer. Characters from cntArr will be sent from the ISR */

TimerEnable(SOC_TMR_0_REGS, TMR_TIMER12, TMR_ENABLE_ONCE);

while(flagIsrCnt);

 

flagIsrCnt = 1;

/* Disable the timer. No more timer interrupts */

TimerDisable(SOC_TMR_0_REGS, TMR_TIMER12); 

}

I have verified that the interrupt table is being properly set for INT10 for the timer, but the interrupt never triggers. I have also verified that the timer0_12 is getting ENABLE_ONCE and that the counter is actually counting.

Perhaps there is something else I overlooked. Here is my init code. Can you take a look?

void USB_init()

{

//

// Not configured initially.

//

g_bUSBConfigured = false;

 

//

    /* Initialize the Interrupt Controller */

//

    IntDSPINTCInit();

//

//Configure the INTC controller for USB

//

ConfigureIntUSB();

DelayTimerSetup();

//

//Initialize the Rx and TX Buffers

//

USBBufferInit((tUSBBuffer *)&g_sTxBuffer);

USBBufferInit((tUSBBuffer *)&g_sRxBuffer);

//

// Pass our device information to the USB library and place the device

// on the bus.

//

USBDCDCInit(0, (tUSBDCDCDevice *)&g_sCDCDevice);

//

    // Clear our local byte counters.

    //

    ulRxCount = 0;

    ulTxCount = 0;

}

Mike,

Is the application still eventually hanging in IntDefaultHandler()?  If so, it still sounds to me like the DSP interrupt (i.e. C674X_MASK_INT10) is not being properly assigned to TimerIsr().  If that mapping appears to be set correctly, then maybe some other (unassigned) interrupt is firing.

One way to debug this issue is to see if we tell what DSP interrupt is actually firing.  I recommend assigning interrupts one by one to a "dummy" ISR function to see when the application goes there instead of to the default ISR.  If we can tell that some other interrupt is causing a spurious ISR call, that would be a big help debugging the underlying problem.  The NMI and "reserved" interrupts (i.e. 1, 2, and 3) may require you to make some minor changes to the system_config library, since the IntRegister() API does not normally allow you to specify a custom ISR for these interrupts.

If none of this helps, then the problem may well be caused by interrupt 10, which is somehow not being assigned to the delay/timer ISR.  If the problem still persists, please zip up your entire project and attach that ZIP file to your next post.  I want to get to the bottom of this.

Joe,

Sorry for the delay.

Joe Coombs said:

Is the application still eventually hanging in IntDefaultHandler()?

Yes.

Joe Coombs said:

One way to debug this issue is to see if we tell what DSP interrupt is actually firing.  I recommend assigning interrupts one by one to a "dummy" ISR function to see when the application goes there instead of to the default ISR. 

I'm really not sure how to do this.

Joe Coombs said:

If the problem still persists, please zip up your entire project and attach that ZIP file to your next post.

Attached.

1881.usb_test_DSP.zip

Also, here is a screenshot of the debug stack showing that as soon as int4 is enabled we go into the IntDefaultHandler(). Not sure if this is helpful.

I notice that, when stepping through the code, the _TMS320C6X pre-defined symbol is valid. However, the imported project "platform_c674x_omapl138_evmOMAPL138" has only two pre-defined symbols; omapl138 and evmOMAPL138. I have re-built the library platform.lib with these two symbols defined, not _TMS320C6X.  Below is the code in question.

/*
** Set up the ARM Interrupt Controller for generating timer interrupt
*/
static void AintcTimerIntrSetUp(void)
{
#ifdef _TMS320C6X
 /* Register the Timer ISR */
 IntRegister(C674X_MASK_INT10, TimerIsr);
  
 /* Set the channel number for Timer interrupt, it will map to IRQ */
 IntEventMap(C674X_MASK_INT10, SYS_INT_T64P0_TINT12);
      
 /* Enable timer interrupts in AINTC */
 IntEnable(C674X_MASK_INT10);
#else
    /* Register the Timer ISR */
    IntRegister(SYS_INT_TINT12_0, TimerIsr);
  
    /* Set the channel number for Timer interrupt, it will map to IRQ */
    IntChannelSet(SYS_INT_TINT12_0, 3);
      
    /* Enable timer interrupts in AINTC */
    IntSystemEnable(SYS_INT_TINT12_0);
#endif
}

The grey section above is greyed-out in my project, but the debugger steps through the greyed-out code section. 

Could this be causing the improper interrupt? What's going on with the pre-defined symbols?

Mike,

The symbol _TMS320C6X is defined automatically by the C6000 compiler.  The symbol checks that you see (i.e. #ifdef _TMS320C6X) allow us to share the same source code between ARM and DSP applications/libraries.  Generally, most of the source code is identical except for a few items, like interrupt APIs.  (Sometimes you will also see code that checks for the symbol __TMS470__, which serves a similar purpose for the TI ARM codegen tools.)

The code you highlighted from the platform library is used to setup interrupts for timer functionality provided by that library.  There is also another piece of code in that library that uses interrupt 11 for a similar purpose.  I don't think that this is what is causing the problem in your application, but I need a little more time to review your code.

Thanks Joe. Looking forward to your update.

Hi MikeH,

Do you find your problem? and how you do this? I have similar problem so it will help me :P

Thanks

Vincent

Hi Vincent,

No, I am currently working on a different (C55xx) project but hope to get back to this in the future.