LPC5461X SDK MCAN ISR Flaw

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

LPC5461X SDK MCAN ISR Flaw

783 Views
jays
Contributor II

In the LPC5461X 2.5.0 SDK there is a flaw in the MCAN routine MCAN_TransferHandleIRQ. It will work fine if there is a single IRQ flag set. If there are multiple IRQ flags set the first will be handled by the if-else code in the do loop and then ALL IRQ flags will be cleared with the MCAN_ClearStatusFlag call in the loop. So if there are TX and RX IRQ flags the TX will be serviced, the IRQ flags cleared and the RX flag never dealt with.

The can.c IRQ code in the old LPC driver seems to be better written (haven't tested it yet though).

FYI: Couldn't find a way to post this to NXP support directly so I posed this here.

Jay S.

0 Kudos
5 Replies

662 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Jay S.

Just wondering how does TX and RX IRQ  occur at the same time ?

BR

Alice

0 Kudos

662 Views
jays
Contributor II

Alice,

There are a number of things that are coming into play here. We are taking the mcan interrupt_transfer example and merging that into our project and using the mcan drivers in the 2.5.0 SDK. Currently for our initial development I've put the mcan interface into internal loopback.

So the interrupt transfer code does a transmit and waits, then does a receive and wait. Once the code is running the mcan IE register just has the RF0NE, BOE, EWE and EPE bits set, no TCE bit set.

So we transmit a frame and when done that will set the TCE bit but not generate an interrupt. With the interface in loop back we receive the frame and get an interrupt.

Now we're in the ISR routine MCAN_TransferHandleIRQ. It does not mask the mcan IR with the IE so it's going to service all the bits set in the IR not just the enabled ones. That is where/how the transmit interrupt it getting processed.

Here I'd like to mention that we're using an A Rev LPC54616 chip for another problem I've found.

Don't know if this is a flaw in the chip or in the mcan driver code.

There is the issue in MCAN_TransferHandlerIRQ when it clears the IRQs by or-ing the original IR register which would clear all IRQs not just the one serviced in its loop. Once I fixed that so that only the serviced IRQ was cleared the problem still existed. All the IRQs in IR were cleared. I tracked that down to MCAN_CLearStatusFlag() which is base->IR |= flags;. That seems to clear the whole IR register. base->IR = flags; works though, it only clears the IRQs masked by flags. Do not know if that is a chip problem or code problem.

Jay S.

0 Kudos

662 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Jay,

1) In the loopback SDK demo, it doesn't use the interrupt function of "MCAN_TransferHandleIRQ()",

call the interrupt function "CAN0_IRQ0_IRQHandler(void)", it is a weak function, so if you the interrupt function doesn't

meet your requirement , you can re-create one for yourself.

pastedImage_1.png

pastedImage_2.png

2) About clear flags, I can reproduced this issue, I will report it to Development team, will reply you after get feedback.

Sorry for the inconvenient to you.


Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

662 Views
jays
Contributor II

Alice,

I was using the boards\lpcxpresso54618\driver_examples\mcan\interrupt_transfer from the 2.5.0 SDK as my base/example code not the loop back example. I put the interface into loop back just for development and testing.  So that was how I was getting interrupts and found the issues.

Thank you.

Jay

0 Kudos

662 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Jay,

Development team think this is a DOC bug, have escalate it.

BR

Alice

0 Kudos