need help setting CAN Rx acceptance mask and filter on a (old) STR73x processor, copied this from the STM32 MCUs Products forum

[mafredette]

I read the CAN section of the RM0001 Reference manuaI STR73x ARMTDMI microcontroller family a few times, but still don't understand how to set acceptance masking and filtering.

I want to only accept CAN extended messages with 29 bit headers that match the following...

x xxx 0000 xxxxxx xx 001001 00 xxx xx

Am I correct that the mask is set in CAN_IF2_M1R and M2R regs? And that a '1' tells the filter to test that bit, a '0' to ignore that bit?

And then, the filter is set in the CAN_IF2_A1R and A2R regs? So the bit values in the unmasked positions of the received header are compared to the bits in corresponding positions in the AR regs? And only if they match, will the message will trigger an interrupt?

So, for my example, I would set...

MR1 = 0 00 111111 11 000 00

MR2 = 0 000 1111 00000

AR1 = x xx 001001 00 xxx xx

AR2 = x xxx 0000 xxxxx

Am I on the right track?

There is a function in the st73x lib and in 73x_can.c, CANSetRxMsgObj() , but it sets both MR and AR, and does not allow setting them independently. Should I just set the regs manually?

[Tesla DeLorean]

https://www.st.com/resource/en/reference_manual/cd00164537-str73x-armtdmi-microcontroller-family-stmicroelectronics.pdf

MR2.15 needs to be ONE for 29-bit extended messages

AR2.14 1=29-bit

AR2.15 1=MsgVal

MR1 = 0x1FE0

AR1 = 0x0480 // xxx0 0100 100x xxxx

MR2 = 0x81E0 // [100]0 0001 1110 0000

AR2 = 0xC000 // [110]x xxx0 000x xxxx

[mafredette]

thank you!

Seems I had understood the concept. In my post I had left off the control bits in the MR2 and AR2 regs on purpose, and thanks for filling them in for me.

I have 2 other comments\questions...

First, here is a function in library in 73x_can.c called

'CAN_SetRxMsgObj(CAN_TypeDef *CANx, u32 msgobj, u32 idType, u32 idLow, u32 idHigh) '

that sets the AR and MR regs based on input params. Not sure how the function is intended to be used - in particular, the relationship between the idLow and idHigh parameters and the bits you want to unmask and then match.  I suppose it is intended to makes things easier than just directly setting the regs. But, in fact, I think it is more straight forward to just set the regs directly. Do you think it's better to use the function?

Second, I thought the mask\filter would only interrupt the processor for a CAN message whose header is accepted. I ran a test and found the rejected messages still cause an interrupt that in-turn causes the ISR in my app to run. I checked that the MR and AR regs are set properly. Is there another reg than needs to be set to enable the mask\filter to not generate the interrupt when the header is not accepted? Or does the interrupt always happen regardless of acceptance and then it's up to the ISR to check the mask\filter result and either continue (if accepted) or quickly exit (if not accepted)?

[mafredette]

I want to better explain my question and observations related to my previous post.

I have successfully programmed the mask\filter using the 73x_can.c lib function CAN_SetRxMsgObj(). I assigned 16 mailboxes as Rx, and set 3 different mask\filters, one for MB 1-4, another for 5-8, and a third for 9-16.

To test it, I apply a variety of CAN packets to the uP. Some match the acceptance filters, some do not.

In the ISR, I look at the IDR for each incoming packet. What I find is that the ISR runs even for packets that do not match any of the acceptance filter. And the IDR for these show '0'. And, for the accepted packets the IDR shows the appropriate mailbox.

My question is whether the ISR should run for the unaccepted packets? Again, I see that it does. But I had thought it would not. Maybe there is another register with a bit that says 'interrupt only on accepted \ interrupt on all'?

mark

[mafredette · Accepted solution]

I contacted ST Support with my question asking whether acceptance filtering blocks interrupts from packets that are rejected by the filter. They answered that for the ST73x, acceptance filtering does not block the interrupts. It is up to the ISR to check the IDR (interrupt identification register) and if == 0, then the packet did not match the acceptance filter and exit without performing any other action.

From support...

"After reviewing the STR73x Reference Manual, it appears that the ISR behavior you described, triggering even for unaccepted CAN packets with the IDR showing ‘0’, is consistent with the expected operation of the MCU."