STM32F042 Is HAL_CAN_ConfigFilter() required?

[Jim Seymour]

Posted on June 18, 2018 at 23:06

I'm trying to get an interrupt-driven CAN receiver working on a STM32F042K6- but I'm not having much luck.

I'veconfigured the CAN module in CubeMX and the code it generates makes sense to me - and seems to match theinstructions listed inthe User Manual.

However,I've seen some posts here that imply that filtering is required. I want to receive ALL messages, so I didn't bother callingHAL_CAN_ConfigFilter(). But I've since addedthat call - but I'm still not receiving anything.

Can someone help me with a simple interrupt-driven receive example?

I'mattaching a subsetof my code. It uses a callback function to set a flag that my main loop inspects. Can anyone see what I might be doing wrong?

Thanks.

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[T J]

Posted on June 19, 2018 at 03:21 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6v4&d=%2Fa%2F0X0000000bxz%2FbJJJkJzcZ1lRO9YFRUFMGpYJXwJV7MyP9JKCt0ix_Co&asPdf=false

[Ben K]

Posted on June 19, 2018 at 18:33

You always need to set up a filter if you want to receive CAN frames. It is not only necessary for filtering out messages, but it also decides to which FIFO the frames will be loaded into. To receive all frames, regardless of type or ID, you need to set up a masking filter where all mask fields are zero.

[Jim Seymour]

Posted on June 19, 2018 at 18:48

Thank you.  It's a shame they don't mention this in the 'How to use this driver' section of the User Manual.

I'll do some more experiments...  (My main problem is that I'm bringing up a new board - so I can't be sure whether what I'm seeing is a software or a hardware issue).

[Ben K]

Posted on June 19, 2018 at 18:57

I can recommend using the loopback mode of the CAN to test whether you have set the peripheral correctly. In loopback mode the transmission line is directly fed back on the receive line, so you can receive your own frames even without a bus or a PHY connected. (The peripheral also ACK-s its own frames.)

[Jim Seymour]

Posted on June 20, 2018 at 00:51

Thanks.  The loopback mode test was a great success.  I can transmit messages using HAL_CAN_Transmit() and receive them via my callback function.

However, when I switch back to normal mode and wire the external CAN pins from one port to another (I have two STM processors on this design), I see no messages - even though I see the TX and RX pins 'wiggle' appropriately.

Tomorrow, I'll connect a Kvaser CAN-to-USB monitor device to see if it can see my CAN messages...

[T J]

Posted on June 20, 2018 at 01:02

When you have the Kvaser running, you will see the BitRate is your last problem.

I guess you have a line driver, but If you don't, you should pullup the CanRx pin.

do you have ABOM enabled ?

[Jim Seymour]

Posted on June 20, 2018 at 01:08

The bitrates look good on our oscilloscope (both messages being sent my the STM and messages being received from our external test device) - so I doubt that's the issue.  (Although anything's possible).

Yes, I have ABOM enabled.  Our device is meant for testing - so I wanted it to give up if it was unable to transmit.

[T J]

Posted on June 20, 2018 at 01:18

What is your current status ?

Tx works ?

Rx works ?

Kvaser is in transit ?

What is your current roadblock ?

[Jim Seymour]

Posted on June 20, 2018 at 01:40

The Kvaser is on my desk. It's just a matter of wiring it in - which we'll do tomorrow.

When I set theCAN port to use loopback mode (via CubeMX), I can transmit and receive the same packet I sent.

When I set the CAN port in normal mode, I get no errors on my calls to _Transmit() - and the pins seem to wiggle properly. (Until I get the Kvaser connected, Idon't know ifthose messages are making it out or not).

Meanwhile, on receive, I call_Receive_IT() and get no errors(*), butnothing ever comes in - even though we see activity on the RX pin with our scope.

(*) I learned late today that you can't call _Receive_IT() from the callback function. The sample code I found (somewhere) did it that way - but (at least in my environment), that results in a BUSYreturn code. I fixed that problem by moving that call to my main loop.