Build Error: FCAN_Config block should have lower priority than ISR block

[rsating]

I get the following build error from the MBDT consistency check when building a model:

Error: block 'EvPowertrainController_HIL/FCAN_Config' . The configuration block should have lower priority than the ISR block (so configuration code gets generated first)! Note: right click on the block, then click on Properties to set Priority.

However, when trying to follow the suggestion, we do not see a "Priority" field in either the Config or ISR block, see below.  How can we resolve this error?

Property pages for FCAN Config block:

Property pages for FCAN Receive ISR block:

[rsating]

For added context, below is the contents of the model with the build error.

I tried deleting the block circled in red, suspecting it may be the source of conflict, but it did not help. Same build error.

[rsating]

It turns out the "Priority" field was accessible by right-clicking "Properties...", instead of "Block Parameters", tried above.  The Target Config block may have been added to the model after the FCAN Config block, giving it a lower priority than the FCAN Config block, which caused the error message. Setting the Target Config block priority to 1 and the FCAN Config priority to 2 (see below) resolved the error.

[mariuslucianand · Accepted solution]

Hello @rsating,

You are right, the message error refers to the priority of the Simulink blocks not the priority of the interrupts on the CPU. Let me explain:

There are two different priorities

1. The Simulink block priority (the ones that you are mentioning here Right click -> Properties...). This priority is used by the Simulink for the code generation block order. A lower block priority will have its generated code executed before the others.

For the CAN peripheral, this order is important because both of CAN config block and CAN receive blocks are inserts code in the initialize function. If the CAN config block is not executed first, then the app will crash, because it will try configure the CAN peripheral before its clock is ungated.

2. The priority of the interrupts. This value is set from inside the ISR block and refers to the hardware priority of each interrupt. When two interrupts will be triggered at the same time, the core will choose to handle first the one with the lowest priority.

Hope this helps,

Marius