i.MX RT1064 Flexcan Breakpoints Breaks Interrupts

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT1064 Flexcan Breakpoints Breaks Interrupts

756 Views
gpearson
Contributor III

I spent a decent bit of time investigating this and couldn't find anything about this (even with NXP Pro support), so after finally solving the issue myself, I wanted to put the info out there for others.

Set up a project using the Flexcan module on the RT1064 - everything worked well, except that, any time I hit a breakpoint while on an active bus (other modules continued transmitting), my CAN interrupts would stop firing after receiving a final kStatus_FLEXCAN_RxOverflow interrupt. (In hindsight, I probably needed to loop through all my message buffers and clear them, but more on that later). 

The MCR FREEZE bit seems to be cleared by default - the RT1064 User Manual states, 

The FRZ bit specifies the FLEXCAN behavior when the HALT bit in the MCR Register is set or when
Debug Mode is requested at Arm level. When FRZ is asserted, FLEXCAN is enabled to enter Freeze
Mode. Negation of this bit field causes FLEXCAN to exit from Freeze Mode.

I take this to mean that, by default, with the FRZ bit disabled (0), the Flexcan module will continue operating even when a breakpoint is hit (debug mode?), thus causing all the interrupts to be missed by the Arm core. Without explicit polling code to clear out the mailboxes, they appear to fill up and then of course after resuming execution, no new messages or interrupts are fired. 

I was able to prevent this from happening by setting the FRZ bit to 1 after initializing the flexcan module, allowing it to enter freeze mode when a breakpoint is hit. 

Anyhow, hope this saves someone else all the digging and troubleshooting I had to go through! (NXP, if you have any thoughts or corrections, I'd love to hear if I understand this correctly?)

 

 

Labels (1)
0 Kudos
5 Replies

273 Views
max_yang1
Contributor III

In the end, I had to recycle every receive MB to recover from overrun. That seems worked well

0 Kudos

292 Views
max_yang1
Contributor III

A bit more detail, another configuration function calls FLEXCAN_ExitFreezeMode(base) (FLEXCAN_EnterFreezeMode(base)), which clears the FRZ bit. I moved code further after that. Now I can sure before I stop debugger FRZ is set. But I can still see kStatus_FLEXCAN_RxOverflow when I can see FRZ is 1. I think the real problem is how can we recover from the overrun.

0 Kudos

324 Views
max_yang1
Contributor III

That is very interesting, I use the 1064 eval board and observed exactly the same behavior. After execution resume, RX stop receiving any message and TX is still working. I checked the FRZ bit was 0.

I tried set it it to 1 at init time, however that seems fault the RX right away, it can receives any message from startup.

Max

0 Kudos

309 Views
gpearson
Contributor III

Hello Max, 

At least in our project, we set the FRZ bit right after calling the FSL driver init code, is this where you're setting it up?

 

    FLEXCAN_Init(can, &flexcanConfig, get_can_clock_freq());


// Allow entering freeze mode
// without this your CAN will stop working after hitting a breakpoint.
    can->MCR |= CAN_MCR_FRZ_MASK;

 

0 Kudos

304 Views
max_yang1
Contributor III
Yes
0 Kudos