cancel
Showing results for 
Search instead for 
Did you mean: 

CAN BUS INTERRUPTS - HAL_CAN_RxFifo0MsgPendingCallback never triggers / I never get the Rx Interrupt.

isca-dim
Associate II

Hello,

My setup is as follows: I have an STM32F469I MCU connected (via SN65HVD230 CAN Board) to the CAN bus of an STM32MP157c-EV1 MPU board which is running Debian.

My goal is to make the MCU send CAN frames periodically to the MPU, and with the CAN Utils on the MPU to receive and transmit to the MCU (candump and cansend).

With the code I am attaching, I am able to transmit from the MCU and receive (candump) in the MPU, but when I transmit (cansend) from MPU to MCU the Rx Interrupt never seems to trigger (I have enabled CAN RX0 and CAN RX1 interrupts in the .ioc, as well as activated notifications in the code).

Is something wrong with the code or is my logic flawed? Why does the interrupt never trigger?

1 ACCEPTED SOLUTION

Accepted Solutions

Sometimes are little things with big issue. ;)

sFilterConfig.FilterActivation = DISABLE;

If you want to enable the Filter you must do it. You don't want to DISABLE it.

Other question:

Why do you call the Error_Handler() function on successful reception?

Toggle a LED will be better. Or use breakpoints.

The 300ms Delay is also a bad idea.

View solution in original post

5 REPLIES 5
TManiac
Associate III

The filter configuration on the bxCAN slave (aka CAN2) is a little bit tricky.

The filter banks are for both controller bxCAN Master and Slave. So the handle on function HAL_CAN_ConfigFilter() will be ignored.

You must select a "FilterBank" higher than the "SlaveStartFilterBank"

This means:

sFilterConfig.SlaveStartFilterBank = 14; 
/* all filter banks above this number will be trigger the slave Rx interrupt */
 
sFilterConfig.FilterBank = 14; /* or higher */

Thanks for the reply but i still get the same behavior :\

Also tried with an identical board and nothing. It's definitely something in the code or maybe in can-utils of linux?

Sometimes are little things with big issue. ;)

sFilterConfig.FilterActivation = DISABLE;

If you want to enable the Filter you must do it. You don't want to DISABLE it.

Other question:

Why do you call the Error_Handler() function on successful reception?

Toggle a LED will be better. Or use breakpoints.

The 300ms Delay is also a bad idea.

I had the filter disabled from previous testing and then forgot to switch it back on :grinning_face_with_sweat: , talk about the little things creating big issues.

To answer your question, the Error Handler was there from the aforementioned previous testing where i was using reverse logic, i.e. if the ID and such were NOT what i wanted... I have also removed the delays :beaming_face_with_smiling_eyes: .

Thanks.

Nice to see a feedback with success :smiling_face_with_smiling_eyes: