S32K NVIC - interrupt ACK

[jakub_mielczare]

Hello,

Is it possible to configure S32K148 NVIC differently, so that it does or does not require register ICPR (interrupt clear pending register) to be written in ISR?

I am observing some strange number of interrupts in AUTOSAR with Category 1 interrupts. When I write ICPR for my IRQ, the number of interrupts is consistent. When I do not write ICPR for my IRQ, then number of interrupts is about two times the expected value.

In my bare metal application I don't see ICPR being written in ISR and the number of interrupts is consistent.

Kind regards,

Jakub

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌,

In autosar OS, the BASEPRI is setup as 0x10, which will not let any interrupt with value greater than or equal to 0x10 to be processed

ENET RX Interrupt is setup as 0x20, which is greater than 0x10 (Please note that the higher the value, the lower priorities), so the processor not process that interrupt when it happens. 

You can check in the AUTOSAR OS code how BASEPRI is setup, or better asking Vector OS team for the reason why they've implemented like that.

Best Regards,

Nam

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌,

So far I haven't seen any clue in S32K HW. Anyway, I think the point here is, when an ACK of Interrupt handler is happened, ICPR will not be set (which means you don't need to clear it), unless the interrupt progress is pending. So I think somehow the interrupt was pending before the ACK of interrupt handler is happened.

Could you take a snapshot of NVIC registers at the time interrupt handler is ACKed, in two case: using your bare metal application, and using Vector OS? I guess there might be some differences between 2 cases, especially with ICPR and IABR (Interrupt Active Bit Registers).

Best Regards,

Nam

[jakub_mielczare]

Hi Nam,

I attached NVIC registers for Autosar and bare metal. The interrupt is first ENET RX interrupt that I get. The interrupt is ACKed by writing 1 to RX Frame flag in EIR register.

Best regards,

Jakub

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌,

I take a comparison, and indeed the Active Bit for ENET RX interrupt (NVIC ID is 74) was not set, while Pending bit for ENETX RX interrupt was set, which means the interrupt was pending, in case of using AUTOSAR OS (on the left). Vice versa, with Bare Metal Application, Active Bit is set, which means the interrupt is acknowledged.

Maybe the interrupt was somehow suspended. Could you take a snapshot of BASEPRI and PRIMASK, compared between your AUTOSAR OS and Bare Metal application?

Regards,

Nam

[jakub_mielczare]

Hi Nam,

Yes, I can take the snapshots. Any other registers you want me to capture? I can do all in single run, will be faster.

Regards,

Jakub

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌,

If possible, please share with me the snapshot for the state of the whole core registers, also the state of the ENET_EIR and ENET_EIMR. I also wanna check the behavior of ENET during the interrupt acknowledgement.

Thank you,

Nam

[jakub_mielczare]

Hi namnguyen‌,

I'm sorry for continuing with such a delay. I was drawn to other tasks.

Please find attached the requested register dumps.

Thank you,

Jakub

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌

 When I write ICPR for my IRQ, the number of interrupts is consistent. When I do not write ICPR for my IRQ, then number of interrupts is about two times the expected value.

I see two points where the action that write to ICPR is taken:

 - void OSPlatformIntcInit(void)

 - void OSPlatformIntcShutdown(void)

Could you describe when did you observe the issue? I supposed it's from OSPlatformIntcInit(), but so far I haven't found any issue in that function. Is that another action from your application code when you say "I do not write ICPR for my IRQ"? 

What do you mean by "number of interrupts is about two times the expected value"?

Regards,

Nam

[jakub_mielczare]

Hi Nam,

I did not mention, that this is with Vector AUTSAR implementation.

When I say "I do not write ICPR for my IRQ" I mean that my interrupt handler function does not ACK the IRQ via ICPR register. And this works on my bare metal implementation.

When I switch to Vector AUTOSAR, I need to ACK category 1 interrupts by writing to the ICPR register in my interrupt handler function.

I am counting the number of interrupts per second and printing it. In bare metal implementation I am getting the expected number of interrupts during  second. In AUTOSAR I am counting my Cat1 IRQs during 1 second and also printing. Here the number is about 2 times higher than on bare metal.

My interrupt source generates known number of interrupts per second.

Regards,

Jakub

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌,

Oh, I thought you're using AUTOSAR OS provided by NXP. Unfortunately, I don't have AUTOSAR OS provided by Vector to check your case. 

From my point of view, it's not necessary to clear the pending interrupt before entering interrupt handler, so I don't know why it's required when using Vector AUTOSAR OS. If this clearing is not mentioned in any Vector OS documentation, then it's better to ask Vector about it.

Regards,

Nam

[jakub_mielczare]

Hi Nam,

OK. But is it possible to configure the NVIC in S32K148 to require or not require the IRQs to be ACKed by ICPR register?

Regards,

Jakub

[namnguyenviet]

Hi jakub.mielczarek2@harman.com‌,

Unfortunately, I have no idea about that. At least with NXP MCAL OS, I don't see that option. Maybe Vector MCAL OS has a different usage.

Regards,

Nam

[jakub_mielczare]

Hi Nam,

How does it look like from S32K HW point of view, is there such possibility?

Regards,

Jakub