arm920T: (serious) Interrupt latency problem

Hi,

I am developing evaluation board using samsung s3c2410 (Arm920T core chip. It is connected DSP which sends interrupt with 0.9ms period to le arm9 check data updates (with 1ms period)in the DSP internal registers. (that means register update and interrupt is asynchronous each other).

It had worked well before (it is compiled using ads c++ compiler). However... It has started losing the updated register (sometimes) after I had adde new task which needs heavy computational loads. In my thought there can b interrupt latency due to the new task.

I guess the size of I-cache can be problem. the size of compiled binar file including the task only is about 60Kb.

the new code took 40 ms to finish and it's loads are just 4 % of overal system (new task's deadline period is one sec and MPLL of arm9 is 20 MHz). Do you think the increase of miss rate of I-cache can be the reason? or are there another problem which increase interrupt latency?

And If I use cache locking, how much speed would I lose?

Thank you for reading...

dungglee.

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
dungglee
Loading thread data ...

On Wed, 17 Aug 2005 17:56:23 -0500, "dungglee" wrote in comp.arch.embedded:

I really think that you need to provide more information. Are you using an RTOS? How much time does this new task keep interrupts disabled, directly or by a system call?

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

I have run into undocumented routines that shut off all interrupts on the TI 6713 DSP platform. I found out the hard way that memset, memcpy etc. turn off all ints and there is no way to fix it unless I write my own versions of those functions.

-howy

Reply to
howard

Thank you for answer. I have used new/delete (c++)command so many times in the new task. It can be a problem too?

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
ansiktet

Thank you for your answer I just used simple RTOS with task switching algorithm (using task stac pointer)programmed by asm. It is not linux kernel etc.

It is convenient to think I did not use RTOS.

And in the new task code I did not use interrupt disable function. instead... if task switching start, interrupt is disabled. and after finishing task switch operation, interrupt is enabled.

I will explain my system:

DSP generate data and flag (which say if data is ready or not)and I ca command DSP to send interrupt with 900 us period. data is generated with 1000 us period. so I can always know whether I can get data from DSP because sampling rat of interrupt is slightly high.

In normal operation with another small size task, it works well. However If I add new hard burden task I can observe the flag ar overwritten without reading.

So I said that there can be interrupt latency. exactly speaking interrupts income correctly but reading function in th interrupt service routine may start with latency.

let

registers.

added

be

binary

overall

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
ansiktet

That doesn't make terribly much sense --- why abuse the DSP as a fixed-rate clock pulse, when it actually *knows* when there's new data, so it could trigger an interrupt at exactly that time?

Unless that task actually disables interrupts, that's impossible. Interrupt latency cannot ever depend on the size of code. If it does, it's either not an interrupt you're talking about, or not its latency, but some other timing parameter.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.