2022-10-05 04:34 AM
I'm trying to just get a CAN message sent out to prove the hardware on a board.
At the moment, the Tx pin is high and even when I attempt to send a message out I get nothing. My first question is:
If there is nothing else attached to the CAN bus (post transceiver, not processor side) does the CAN module on the STM32 even attempt to send anything out?
Second question:
Is there anything else other than following that needs sorting to send something out:
Many thanks for any pointers, suggestions.
2022-10-06 06:59 PM
DiBosco,
It's been a long time since my first work with CAN with these processors and my memory is definitely faded on this, but I think you are correct in thinking that it won't send anything if there is nothing on the CAN bus. However, as I remember it can be setup up for a loop-back.
My most recent case where the TX was not sending, with a new board and new software was that I had copied/hacked the CAN routines from a working program from an earlier board, but the CAN pins the new board were different. As usual in retrospect, a silly mistake, but it doesn't look that way at first. Moral: double check the simple basics just be sure.
2022-10-06 09:23 PM
If you examine the CAN status registers you'll find the TX error threshold has been exceeded, automatically disconnecting the CAN peripheral from the bus. This is a reliability feature, sort of a "flooding TX node" watchdog, and can't be disabled. A working CAN bus requires two nodes, with transceivers, twisted-pair interconnect, and 120 ohm terminating resistors at each end. The bus will not arbitrate with a single node.
You can enable the internal loopback mode for software testing but to check hardware you need a transceiver and a second node. You won't be able to test with your current setup.
2022-10-07 01:31 AM
Thanks to you both for the help. I've ordered a USB to CAN analyser/transceiver to help me debug and have another node on the bus.
2022-10-07 04:26 AM
>>I'm trying to just get a CAN message sent out to prove the hardware on a board.
What about the loopback mode? its actually hardware
2022-10-07 05:01 AM
"What about the loopback mode? its actually hardware"
That doesn't help because I have to test the physical routing outside of the micro. It's getting routed through a couple of relays that switch between 485, 232 and CAN.
2022-10-07 06:13 AM
Hello,
To be able to send/receive CAN messages in Normal mode you have to set up a minimal CAN bus:
Two nodes having each CAN transceiver connected to the CAN bus with 120 ohm termination resistors.
CAN is not SPI or UART to test it in standalone except in Loopback mode.
2022-10-11 07:48 AM
I've finally had success with CAN1, can get mesasages in and out now, but not so with CAN2.
In the data sheet (for the F429) is says CAN2 is a slave peripheral. What does that mean? Slave to what? Surely you can send and receive messages out and in with it, just like CAN1?
2022-10-11 07:57 AM
First of all, It's better to share how did you solve the issue with CAN1.. to help others in community to find answers.
Second, CAN2 is not a slave from CAN protocol point of view but it's a slave
of CAN1 from internal implementation point of view.
CAN1 and CAN2 share the same memory and filters, but only CAN1 manage
them directly. In order to allow CAN2 to access these ressources, CAN1
should be enabled (RCC CAN clock enable).
So, CAN2 can be used without using CAN1, but the latter's clock should
be enabled in order to allow CAN2 to access the filters and internal
CAN memory.
2022-10-11 08:53 AM
Thanks for clearing up the CAN2 slave question.
I should start by saying I have both CAN1 and CAN2 implemented on my board with identical circuitry.
I solved the problem by getting a second node on the bus and putting 120R termination resistors as suggested above. Could eventually see with the scope that I was getting messages out of the CAN transceiver (into the STM32) by putting my scope on the Rx pin of the CAN transceiver. It became clear the data I was getting into the pin of the STM32 was the correct data. (My scope has various serial protocol decoders on and it was showing what the USB<->CAN (simplyCAN) device was sending out was coming out of the transceiver's Rx pin.)
The simplyCAN device was saying there were errors still though when transmitting. Originally I had simplyCAN connected to CAN2, so for ****s and giggles I connected it to CAN1 instead. At first it didn't work, then I realised I wasn't clearing the INAK for CAN1 and once that was cleared, lo and behold, it suddenly worked. As far as I can see the software set up is now identical for both yet CAN2 does not work, hence me questioning what slave means.
CAN2 when it tries to send out sends short pulses periodically on Tx line and you can see that coming to CANL and H, but it never tries to send out a full messages, so there's clearly something not quite right and I think it must be a software issue.