Vector #: 636 0x27c
Offset : 159 0x9f
Task Id: 0x10005 Td_ptr 0x1000bc80 Stack Frame: 0x100006f8
Interrupt_nesting level: 2 PC: 0x000006ea SR: 0x2204
I have the same issue.
I am also using the FlexCAN module and have messages being received about every 50ms. This interrupt only triggers on my code when I hit a breakpoint and then try to resume execution. At the time I resume execution , the interrupt occurs.
I have been able to temporarily work around the problem by actually installing an interrupt handler for the MCF5225_INT1_rsvd31 interrupt (I am just using my regular FlexCAN_ISR interrupt handler).
To make this work, I had to modify the M52259ev.h file and change the BSP_LAST_INTERRUPT_VECTOR_USED value to be MCF5225_INT1_rsvd31 and then rebuild MQX.
This seems to fix the problem (at least for now).
It sems to me that there is a real (undocumented) interrupt happening. Iit appears to me to be some kind of CAN overrun error that is occurring while I am sitting at a breakpoint in the debugger.
I plan on submitting a problem report to see what can be done about it.
Hello SoftwareForHire,
I have the exact same problem. I'll try what you did.
Did you finally get an answer from Freescale?
Help is appreciated.
So be it. I'll give it a try. I posted a Technical Service Request, hopefully these guys make a good job in clarifying why in the world we're getting an interrupt caused by --supposedly-- unused sources. I'm getting unhandled interrupts from vectors 151, 157 and 159 very consistently.
Thanks for you prompt reply!
I found the problem. I hope this helps to all other people experiencing it.
- First the MCF52259 microcontroller device --possible others, too-- has some undeterministic behavior when the ICR registers are set to the same values. "MCF52259 ColdFire® Integrated Microcontroller Reference Manual, Rev. 4", page 16-10 states: "It is the responsibility of the software to program the ICRnx registers with unique and non-overlapping level and priority definitions. Failure to program the ICRnx registers in this manner can result in undefined behavior."
I find this as a major drawback on the device design. A microcontroller should be a deterministic machine. There should be a mechanism that solves concurrent interrupts of the same configured priority.
- Second, MQX does exactly what the manual says not to do. In function FLEXCAN_Int_enable, called as follows:
FLEXCAN_Initialize_mailbox -> FLEXCAN_Int_enable -> _flexcan_int_init
... the ICRs associated with the CAN mailboxes are set to a predefined interrupt level and sub-level...
Check: _flexcan_int_init (index, FLEXCAN_MESSBUF_INT_LEVEL, FLEXCAN_MESSBUF_INT_SUBLEVEL, TRUE)
This caused a our application - heavily dependant on CAN @500 kbps- to generate continuous resets and therefore to not function at all.
I think that Freescale needs to address this issue in their next MQX release.
My setup:
MCF52259 in a custom developed board, using CAN @ 500 kBit/s
CodeWarrior 10.2
MQX 3.8
Hi lumi,
Sorry for the hassles and thank you for posting your solution.
I will forward this to our MQWX Development team.
Regards,
David
Hi,
How interesting. Just updated our app to use the latest MQX and suddenly things started failing... I started getting some occasional unhandled exceptions and all this strange behavior sounded kind of familiar. After a little investigation I come to the forum, see my own solution, go check the MQX CAN driver and find that in version 4.0.2 it still has the same error.
The line...
_flexcan_int_init (index, FLEXCAN_MESSBUF_INT_LEVEL, FLEXCAN_MESSBUF_INT_SUBLEVEL, TRUE)
... does exactly what the manual says not to do: setting the same interrupt level and sublevel to different exception sources.
Freescale: Please resolve this bug in MQX!
Thanks,
Luis
I found the problem. I hope this helps to all other people experiencing it.
- First the MCF52259 microcontroller device --possible others, too-- has some undeterministic behavior when the ICR registers are set to the same values. "MCF52259 ColdFire® Integrated Microcontroller Reference Manual, Rev. 4", page 16-10 states: "It is the responsibility of the software to program the ICRnx registers with unique and non-overlapping level and priority definitions. Failure to program the ICRnx registers in this manner can result in undefined behavior."
I find this as a major drawback on the device design. A microcontroller should be a deterministic machine. There should be a mechanism that solves concurrent interrupts of the same configured priority.
- Second, MQX does exactly what the manual says not to do. In function FLEXCAN_Int_enable, called as follows:
FLEXCAN_Initialize_mailbox -> FLEXCAN_Int_enable -> _flexcan_int_init
... the ICRs associated with the CAN mailboxes are set to a predefined interrupt level and sub-level...
Check: _flexcan_int_init (index, FLEXCAN_MESSBUF_INT_LEVEL, FLEXCAN_MESSBUF_INT_SUBLEVEL, TRUE)
This caused a our application - heavily dependant on CAN @500 kbps- to generate continuous resets and therefore to not function at all.
I think that Freescale needs to address this issue in their next MQX release.
My setup:
MCF52259 in a custom developed board, using CAN @ 500 kBit/s
CodeWarrior 10.2
MQX 3.8