STM32 - CAN Filter - Possible to filter data for standard frames?

[Whiterat]

Hi,

When operating in single 32bit filter mode, is it possible to use this additional space to check the first byte of the message data/payload when dealing with standard frames?

I have an issue with a particular ID "spamming" every 500ms or so and am only interested in messages starting with a particular byte.

If I could filter to this byte it would make ISR viable again.

Thanks.

[Tesla DeLorean]

I don't think it reaches into the payload.

The filter mechanism is inherently quite simple, it is the bits as seen on the wire, in that order, so the messages can be quickly binned into the appropriate queues for processing or to be ignored.

The method is done in hardware, with a shift-register, an AND Mask and a Comparator. It's is not configurable, it is just a selective pattern matcher.

[Whiterat]

Thanks for the reply.

Bare with me as I'm relatively new to working with the STM32 platform.

The MCP2515's filter just looks at the top 29 bits regardless of it being a standard or extended frame which gave the benefit of being able to filter against the first 2 bytes of the payload in a standard frame.

I was hoping the same might have been possible with the STM32 so this troublesome keepalive frame I'm trying to "ignore" doesn't end up in the queue.

So I'm guessing there's some logic somewhere that based on the IDE bit that if it's standard frame it then only uses 16bit of the filter and mask?

As otherwise if it was just filtering exactly what's on the wire regardless of frame type, I would be able to achieve what I'm after.

[Tesla DeLorean]

It's 30 bits deep before it gets to the IDE bit, and it's a bit you're comparing. The rest of the packet hasn't arrived yet, and the controller has made a take it / don't take decision by then. The CAN IP ST bought doesn't do frame level filtering.

500 ms is a long time. What rate are you getting interrupts? The trick is to not spend a lot of time dwelling in the service routine, and queue the packets you want to process in a worker thread/task

[Whiterat]

That's not as I understand it. The IDE bit is always bit 13 (14 if including SOF) on the wire for standard or extended frame.

As it sits on the wire, payload data would start at bit 19 on a standard frame, which would be in the middle of the extended frame identifier.

So since a 32bit filter has the ability to filter a whole extended frame ID, technically it should be able to filter into the payload of a standard frame ? At least in terms of the number of bits we're looking into - UNLESS there's something funky going on depending on the IDE bit.

The ISR is pretty simple currently, if interesting frame then set a flag for the loop to deal with it - but it does mean I'm having to read the whole frame every time just to dismiss the irrelevant ones. Whilst the F103 isn't the highest spec, it should be capable.

[Tesla DeLorean]

It might be able to use bits which fall into the place of the EXID bits, you'll have to experiment with the mask/compare register.

Perhaps figure out where the DLC bits reside, sweep the EXID space with one bit so you can filter ODD size packets, as you cycle thru the possible packet lengths.

I haven't seen any bxCAN implementation/use documentation covering this method, but if you can generate traffic it shouldn't take long to PoC

[Ozone]

> It might be able to use bits which fall into the place of the EXID bits, you'll have to experiment with the mask/compare register.

Iwould agree with that.

Albeit I have a hunch the filters are trimmed to the address modes.

[Whiterat]

> Albeit I have a hunch the filters are trimmed to the address modes.

Sadly that's very much my hunch too at this moment.