Hwi_setPriority problem.

What device are you using?

TMS570LS20216, cortex R4

Hi Simon,

Is this the same issue as:

    http://e2e.ti.com/support/embedded/f/355/p/128771/462178.aspx#462178

Alan

Hwi_setPriority() is used to initially set the interrupt priority at Hwi create time so I suspect it works (at least some of the time).

Can you provide details on the other interrupts in your application? (ie how many, which ones, what priorities, frequency, etc).

I'm wondering if you are setting the timer interrupt to a priority lower than an interrupt that is ALWAYS active, which would result in the timer interrupt never getting serviced.

Are you properly servicing (ie acknowledging) the other interrupts in your system? If not, they can remain active after returning from the interrupt handler and cause an immediate return to the interrupt handler again.

Alan

I've got 3 interrupt sources:

First one:

VIM 2: RTI, which is the clock tick of the bios. It is selected by the XDC tool. At 1Khz. I do NOT clear the interrupt of this one since I thought it is done by the framework (RTOS).

Second one:

VIM 10: NHET, which is my highest frequency interrupt at 16Khz. The flag is cleared this way at the beginning of the thread callback:

volatile unsigned vec = regNhet.hetOff1.all;

Third one:

VIM 16: CAN interrupt, which is asynchronous.   The flag is cleared this way in the middle of the callback function.

// - Setup IF2 for clear pending interrupt flag
while( canPtr->if2.cmd.bit.busy == 1 );

So my goal is to lower the RTI interrupt, after the CAN interrupt.

Simon

When you refer to the "callback function", is that the function passed to Hwi.create() or is that a function called by a Swi that is posted by the ISR?

The function passed to Hwi.create() at run-time before Bios_start.

Simon

Can you provide a dump of the contents of memory from 0xfffffe00 thru 0xfffffd00 before and after your call to Hwi_setPriority()?

I want to know what is being written to the VIM's channel map registers.

Alan

I've reviewed the channel map register definition a little more.

Depending on my state of mind I can interpret it two ways.

Try reversing the argument order in Hwi_setPriority() and see if you get better results:

    Hwi_setPriority(TMS570::DrvVim::VIM_HET_HIGH + 1, 3)

Alan

This is the dumps.

The int 3 doesn't came anymore after this.

1108.memory_after.txt

1881.memory_before.txt

Simon

I've tried to reverse parameters order. It runs yes, but I have to way to know if the priority has been applied.

Simon

I finally had a chance to look at the memory dumps you provided.

From the contents of the channel map registers, It appears to me that you are setting interrupt #3 to the priority of 11.

Is that correct?

If my theory regarding argument order is correct, the effect of calling Hwi_setPriority(3, 11) would be to set interrupt 11's priority to 3.

If you don't use interrupt 11 in your system then I don't see how this seemingly benign misconfiguration of an unused interrupt could cause any trouble. Which makes me think that Hwi_setPriority() is coded correctly.

If Hwi_setPriority() is coded correctly, then it seems to me that you have lowered int #3 to priority 11 successfully and by doing so, another higher priority interrupt is going off all the time and never allowing int #3 to run.

Alan

Using xdc.runtime.Timestamp, Is it possible for you to measure how long the processor is within the 16KHz interrupt handler?

UInt start, end, delta;

start = Timestamp_get32();

... /* your ISR code here */

end = Timestamp_get32();

delta = end-start;

You can monitor the 'delta' variable using CCS and verify that it doesn't exceed 1/16000 = 62.5 uS.

The R4 timestamp counter is clocked at the R4 CPU frequency.

Alan

« From the contents of the channel map registers, It appears to me that you are setting interrupt #3 to the priority of 11.

Is that correct? »

Yes that's correct, this is what I want to do.

And I do NOT use int 11 in my system.

I'll try to disable the other interrupt and see if int 3 works with priority 11.

Simon

I do not use the xdc.runtime.Timestamp but we use the performance monitoring built-in in the TMS570, which calculates precisaly the number of instructions between 2 points.

And my measure showns for sure that it doesn't exceed 62.5us.

Simon

(sorry I've send this post somewhere else by error, I repeat it here)

I do not use the xdc.runtime.Timestamp but we use the performance monitoring built-in in the TMS570, which calculates precisaly the number of instructions between 2 points.

And my measure showns for sure that it doesn't exceed 62.5us.

Simon

The xdc.runtime.Timestamp module routes it's Timestamp_get32() function to a device specific implementation, which in this case ALSO uses the R4's internal performance monitor counters...

I measure it also with an oscilloscope, I sure at 100%.

That's good XDC tool uses the performance monitoring, I'll eventually switch to use this interface.

Simon