Interrupt duration in core1 is extended

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Interrupt duration in core1 is extended

1,147 Views
harryhoehn
Contributor I

Hi,

I use the MPC5676R controller with iSYSTEM debugger and GNU compiler. Both cores have separate timer interrupts. For core0 an eMIOS counter is used (every 100μs, priority 10) and for core 1 an RTI interrupt (every 30μs, priority 15).

While the interrupt on Core 0 is running normally, the interruption time is sporadically increased in the core1. The duration of the interrupt routine then extends from approximately 3.5μs to over 35μs for the same number of instructions. It seems as if only the interrupt routine is extended, not the routines in the main loop.

  • The first thought was that the core0 interrupt slowed down the core1. For testing, the interrupt in the core 0 was therefore tentatively blocked. That was without success.
  • The second attempt was to change the priorities of the XBAR in favor of the core 1. Again without success.
  • In the next step, the RTI interrupt has been moved to core0. Except for the priority conflicts, both interrupts ran correctly, but this solution is not really useful.

What else can be the reason that the interrupt timing in core 1 slows down?

Tags (2)
2 Replies

991 Views
harryhoehn
Contributor I

I'm not sure if the cache is set correctly (see attachment). Only the flash uses the cache. This should work on both cores, I think.

Harry

0 Kudos

991 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

So the execution time of your interrupt is prolonged only on core1.

What about cache? branch target buffer?

Things that have influence on instruction execution.

Peter