• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 400 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dsplink 1.65.00.02 notify interrupt generation - unlocking of KICK0/1 registers needed for OMAP-L138

Gunter Schmer
Genius 14312 points


Hi,

 

one of my customers has brought up an issue with the dsplink notify component in which the GPP was unable to generate an interrupt to the DSP. After the customer was doing a lot of debug, he found a potential issue with the KICK0/1 registers being in a locked state. The current workaround is to add code in the da8xxgem_hal_intgen.c to unlock the KICK registers everytime before the interrupt bit is set. This allows the interrupt to be generated correctly and the DSP can see it.

The following code was added to da8xxgem_hal_intgen.c

 

 

 

 

 

 

 

case DSP_IntCtrlCmd_Send:

{

index = ARM2DSP_INT_INDEX (intId) ;

addr = halObject->baseCfgBus

+ halObject->offsetSysModule

+ OFFSET_CHIPSIG ;

index = ARM2DSP_INT_INDEX (intId) ;

 

 

/* Unlock the kick0 area */

*((

volatile Uint32 *) ( halObject->baseCfgBus

+ halObject->offsetSysModule

+ OFFSET_KICK0 )) = KICK0_UNLOCKVAL ;

 

/* Unlock the kick1 area */

*((

volatile Uint32 *) ( halObject->baseCfgBus

+ halObject->offsetSysModule

+ OFFSET_KICK1)) = KICK1_UNLOCKVAL ;

SET_BIT (*((Uint32 *) addr), (index + BITPOS_ARM2DSPINTSET)) ;

}

 

 

break;

Can the DSPLINK team confirm that this is a necessary change? Has there been a later version of DSPLINK in which this is fixed?

Thanks,

--Gunter

  • 0
    TI__Expert 6860 points

    The use of the Kick register has been a source of issues in the past.  What has been done in DSPLink for some time now is to unlock the KICK register at start-up and leave them as so thus indicating that there is something else in the system (driver, user application code, etc) that is locking these registers.  The above workaround looks fine but it would be strongly recommended that the code that locks these registers be tracked down as DSPLink only unlocks them and never touches them again.

    Arnie

  • 0 in reply to Arnie Reynoso
    TI__Expert 6860 points

    Additional Note:  Though the workaround may work in majority of cases, their is a very minute possibility that an interrupt may get lost thus the previous recommendation to track the source that's locking the KICK registers.