MPC5746R Hardware Interrupts

[mgrabau_holley]

Good Day,

We have been trying to get the hardware vectoring setup working as described in Chapter 17 of the subject processor's reference manual. Thus far, we have been enabling hardware vectoring but the processor is raising an exception (either 0 or 1) into VTABLE (the address set IPVR). Are there any code samples available for configuring the hardware vector mode? I have found the pseudo-code in section 17.8.2.2 of the reference manual, but I seem to be missing something.

Thank you,

Mathew

[martin_kovar]

Hello Mathew,

I have created two examples, which shows, how to use Hardware Vector mode. You can use the one, which is created for MPC5744P (you have to edit interrupt vector table, but most of the example is usable for you). Please see the following link and let me know, if you have any other questions.

https://community.nxp.com/docs/DOC-332022 

Regards,

Martin

[mgrabau_holley]

Hi Martin,

Thank you for the very helpful example. It was enough for me to get the hardware vectoring working.

However, I am having a new problem now. After the handling of the interrupt, the CPRn value remains elevated (it seems the LIFO pop that is done after the branch to the C function is not working properly).

Do you have any suggestions for that? I reviewed the code against what is listed in other threads and it seems fine. It is the FlexCAN peripheral and I can see that the IFLAG for the mailbox is being cleared. 

I can successfully get the interrupt to trigger that one time, but after that it just sits in my main loop. I can see the frames being received into the MB structures, but the interrupt does not trigger again.

I have reviewed the contents of other threads to no avail. Any additional information would be greatly appreciated.

Any thoughts?

Best regards,

Mathew

[mgrabau_holley]

Hi Martin,

I discovered the change that was required at the top of handlers_vle.s:

# Original line: .equ INTC_EOIR, 0xFC040030

.equ INTC_EOIR, 0xFC040034

The code in specific was executing on Core 1 and not Core 0. Changing that definition fixed the priority issue that I was witnessing.

Thanks!
Mathew