TMS320C6678: HWI ALL mask option is not working

malek alashiri

Part Number: TMS320C6678

hello

we have one SRIO doorbell interrupt and one timer interrupt. we set SRIO interrupt maskSetting to Hwi_MaskingOption_ALL. but it seems that our SRIO ISR is getting preempted by timer ISR.

we are using time64 of SYS/BIOS and for SRIO Doorbell we are using cpintc. here is function that perform interrupt activation for cpintc module (our SRIO):

int LinkingInterrupts(unsigned int sysInt, unsigned int hostInt, unsigned int cicId, int allMask, unsigned int coreDstIntId, CpIntc_FuncPtr fxn)
{
	volatile int errCode = 1;
	int eventId;

	Hwi_Handle hwi0;
	Hwi_Params hwiParams;

	Hwi_Params_init(&hwiParams);

	CpIntc_dispatchPlug(sysInt, fxn, sysInt, TRUE);

	CpIntc_mapSysIntToHostInt(cicId,sysInt,hostInt);
	CpIntc_enableHostInt(cicId , hostInt);
	CpIntc_enableSysInt(cicId, sysInt);
	eventId = CpIntc_getEventId(hostInt);

	hwiParams.arg = hostInt;
	hwiParams.eventId = eventId;
	hwiParams.enableInt = TRUE;
	if(allMask)
		hwiParams.maskSetting = Hwi_MaskingOption_ALL;

	hwi0 = Hwi_create(coreDstIntId, CpIntc_dispatch, &hwiParams, NULL);
	if(hwi0 == NULL)
	{
		errCode  = 1;
	}
	else
	{
		errCode  = 0;
	}
	return errCode;

}

over 3 years ago

0 lding over 3 years ago

TI__Guru* 95265 points

Hi,

In the C66x, there are INT4, INT5.... INT15. The lower number has higher priority. This is the coreDstIntId in your hwi0 = Hwi_create(coreDstIntId ,....). Please assign SRIO higher priorities than timer. Also use Hwi_MaskingOption_SELF,

typedef enum Hwi_MaskingOption {

Hwi_MaskingOption_NONE,

Hwi_MaskingOption_ALL,

Hwi_MaskingOption_SELF,

Hwi_MaskingOption_BITMASK,

Hwi_MaskingOption_LOWER

} Hwi_MaskingOption;

VALUES

MaskingOption_NONE — No interrupts are disabled

MaskingOption_ALL — All interrupts are disabled

MaskingOption_SELF — Only this interrupt is disabled

MaskingOption_BITMASK — User supplies interrupt enable masks

MaskingOption_LOWER — All current and lower priority interrupts are disabled.

This is what I see in the https://processors.wiki.ti.com/index.php/Configuring_Interrupts_on_Keystone_Devices.

Regards, Eric

0 malek alashiri over 3 years ago in reply to lding

Intellectual 680 points

hello

thank for your reply

Timer is using INT8 and SRIO is using INT6, so problem is not from priority.

and about using MaskingOption_ALL I should say that it's necessary for our application to use all mask option because we don't want any other interrupt be able to preempt us while we are in SRIO doorbell ISR. we don't want to use Hwi_enable() and Hwi_disable() to do that, so we decided to use MaskingOption_ALL.

0 ScottG over 3 years ago in reply to malek alashiri

TI__Mastermind 26780 points

Malek,

Your Hwi creation code snippet looks OK, as long as the “allMask” parameter is true.

I’ve checked and there aren’t any known issues with Hwi_MaskingOption_ALL.

A few questions:

How are you determining the timer interrupt is preempting the SRIO interrupt?

Are you able to set a breakpoint in CpIntc_dispatch() and look at the IER bits?

Is it possible that 'fxn' (or some other function plugged with CpIntc_dispatchPlug()) is somehow changing IER bits?

Have you tried using the ROV tool to check kernel state, for example to be sure there isn’t maybe a stack overflow or other problem?

Which version of SYS/BIOS are you using?

Thanks,
Scott

0 malek alashiri over 3 years ago in reply to ScottG

Intellectual 680 points

hello

sorry for late response, here is answer to your questions:

1. we used TSCL to measure SRIO ISR execution time, since it was a logic free and fix operation we expect for measured time to don't have too much variation but it wasn't the fact. in fact SRIO ISR time was changing drastically. then we used Hwi_disable() and Hwi_enable() in the beginning and end of SRIO ISR which results in to fix execution time of SRIO ISR. from this we reach to this conclusion that some other HWI is preempting SRIO ISR and since there was no other candidate except timer, we assumed that this is Timer interrupt that preempting SRIO ISR. (since we have no UIA)

2. this part will take a little time since i myself don't have direct access to test setup. but if i could do that i will let you know.

3. no it was not possible, at least as much as i'm aware of.

4, 5. no, since our bios version is too old (6.33.4.39), i assumed that we won't be able to use ROV (Since ROV is part of UIA).

please notice that we are taking about a finished product so upgrading sys/Bios version is nearly impossible unless there was a good reason for it, for example if you prove that our problem originate from our outdated Sys/bios

thanks in advance

0 ScottG over 3 years ago in reply to malek alashiri

TI__Mastermind 26780 points

Malek,

Thank you for these responses.

And sorry for my slow reply, I’ve been out of office.

I looked back in our older bug database going back 8 years and still see no reported issues with masking. Your test to use Hwi_disable() to see fixed execution for the ISR does point to unintended IER bits. But it isn’t clear to me that this is at entry to Cpintc_dispatch() or during that execution. Also, just a side note, to be safe in this case, Hwi_restore() should be used versus Hwi_enable().

ROV isn’t part of UIA, it comes included with CCS. You should find it under the “Tools” menu. Depending upon your CCS version this may be listed as “ROV” or “Runtime Object Viewer”. It is a stop-mode debug tool. If you have debugger access you should be able to run it.

Are you able to attach a debugger to the device to help narrow down the problem? Or are you limited to program-only access?

If you only have programmatic access to the device, is it possible to read and report the IER value at the start of the ISR? Maybe write a test function that you specify to Hwi_create(), which reads IER then calls Cpintc_dispatch()? You can access IER from C using the “__cregister” keyword to declare "IER":

extern __cregister volatile unsigned int IER;

Regards,
Scott

Processors

Processors forum

TMS320C6678: HWI ALL mask option is not working