Part Number: TMS320C6678
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;
CpIntc_dispatchPlug(sysInt, fxn, sysInt, TRUE);
CpIntc_enableHostInt(cicId , hostInt);
eventId = CpIntc_getEventId(hostInt);
hwiParams.arg = hostInt;
hwiParams.eventId = eventId;
hwiParams.enableInt = TRUE;
hwiParams.maskSetting = Hwi_MaskingOption_ALL;
hwi0 = Hwi_create(coreDstIntId, CpIntc_dispatch, &hwiParams, NULL);
if(hwi0 == NULL)
errCode = 1;
errCode = 0;
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,
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to lding:
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.
In reply to malek alashiri:
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
In reply to ScottG:
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 (188.8.131.52), 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
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
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.