How to minimize code generation into Interrupt Handler

Showing results for 
Search instead for 
Did you mean: 

How to minimize code generation into Interrupt Handler

Contributor II

Hello NXP MBD Community,

I've recently figured out that in case of using CTU for triggering Subsystem (over Trigger Port, function-call) and the following Sybsystems in the chain, the generated code for these blocks just inserted into IRQ Handler. For example, I analyzed code from example model PMSM_OpenLoop_mpc5744p.slx and I can see that all math from ADC Sensing, Measurements, IRQ_Dispatcher and rest subsystems from Simulink model are in the IRQ Handler. 

So this type of task handling can reduce reaction of whole system in case if use additional interrupts which will not be synchronized. The main rule for interrupts handing is do not stay in IRQ handler too long and do not block another interrupts which can happen.  

Is there any way to exclude generated code from subsystems in the MBD?

0 Kudos
1 Reply

NXP Employee
NXP Employee


This is a very interesting observation. In general yes, I agree with your statement that you should spend as little as possible in the IRQ Handler. Anyhow in this scenario I do not think it is a problem since you cannot have another CTU interrupt triggered within 100us (as per application setup where the fast control loop is executed at each 100us based on PWM-CTU-ADC synchronization) 

If you have other interrupts in the system, then of course it is possible from the Simulink block options to change the priorities of the the interrupts to allow a potentially higher interrupt to stop the execution of the CTU Handler. Nonetheless, in motor control applications, I consider the most important execution flow, should be the fast control loop, hence it shouldn't be interrupted except for the potential FAULTS.

We can potentially show you how to change the generated code for the IRQ Handler in order to call the function that handles all the computation after the clear flags. That can be easily done from the Simulink block associated TLC file.


Also, if you want to spend as little as possible in the IRQ Handler, you can also remove some of the computations related with protections for Vdc/Idc which can be called in the Simulink step function/Slow Loop rather than Fast Loop function.

The phase current measurements and FOC computations need to be synchronized with the actual ADC measurements and PWM generation, hence you cannot have them de-synchronized.

What you can do instead, is to reduce the CPU load by implementing the whole MC algorithm in fixed-point precision 16/32b and avoid unnecessary scaling between PU->SI system of units. This way you will further reduce the time spent in the CTU IRQ handler and give more time to spend in the main() for being ready to handle any other potential interrupts.

Furthermore, if you want to remove the ***_CTU_IRQ_Handler() from the CTU callback, then you can do it by removing the function call in Simulink, but you will need a sort of Timer Interrupt or Simulink Step time at 100ms to compute the FOC. Since the sources for all timers are the same in the CPU, you should not get a time drift. With the appropriate volatile variable handshake between CTU interrupt and Fast Loop() you should be able to deal with the task of controlling the motor.

Simulink allows you to define multiple tasks (see this article: (How-to) Multitasking on S32K144 MBDT Simulink ), by setting the execution time for each block, hence it should be relatively easy to change the model to match your own expectations.

Hope this helps!


0 Kudos