Hi there, I have problems setting up the two CAN ports on the MCBSTM32C demo board. I got them to work in loopback mode but in normal mode the INAK bit doesn't set itself to 0.
In the manual it says that the hardware has to monitor 11 consecutive recessive bits to initialise. How to you sent the bits to the port if none of the CAN ports are working? Do I have to set up CAN1 in loopback mode, send 11 bits to CAN2, switch CAN1 to normal mode and then use CAN2 to send 11 bits to CAN1?
The other possibility might be that I didn't set up the CAN ports correctly. Has anybody got an example how to set up the clocks and all the other registers to make CAN1 and CAN2 work?
Thanks, Karsten
Hi Per, Thanks for your reply.
I only connected CAN1 of the demo board to CAN2 with a 60 Ohm resistor between the CAN+ and CAN- pins. I want to send messages between CAN1 and CAN2 for testing purposes.
As far as I understand it a recessive bit is when there is no voltage across the CAN+ and CAN-pins.
I'm assuming the 11 consecutive recessive bits have to be flanked by dominant bits. Otherwise not sending anything would be sufficient to synchronise the CAN port. If my assumption is correct the CAN port would have to receive a base frame with an identifier of 0x7FF and a dominant RTR bit. One of the nodes on the bus would have to send such a frame. Is this correct?
In this particular case this would be possible via the loopback mode. Later on I would like to read data from a CANopen position encoder attached to only one of the ports. In this case the encoder would have to send such a frame until communication has been established. I'm not sure yet if CANopen sends such a sync frame at power up by default.
I'm assuming the 11 consecutive recessive bits have to be flanked by dominant bits.
Why?
Otherwise not sending anything would be sufficient to synchronise the CAN port.
What do you assume it would have to synchronize with?
Is this correct?
No.
The CAN controller expects to see "silence" on the cable. When it then has something to send, it will try to start to send, while checking if there is a collision. The design with dominant and recessive bits means that collisions can always be detected. And if two CAN transmitters starts at exactly the same time, they may both continue to send until one of them sends a bit that differs from the other. Then the one who did send a recessive bit will notice that it failed and will stop further transmission, while the controller sending a dominant bit didn't notice any problems and can continue to send the rest of the frame.
So any bit in the frame can be deciding if one CAN transmitter should stop and retry later, or if it has still managed to transmit exactly what it expects and are allowed to continue to transmit. This then implies that the ID of a CAN frame also represents a priority, in case a collision isnt detected until the transmission have reached the ID.
For some reason the Initialization acknowledge bit (INAK) does not clear when I request to leave the initialization mode. The following is a quote from the manual in the INAK bit description:
"This bit is cleared by hardware when the CAN hardware has left the initialization mode (to be synchronized on the CAN bus). To be synchronised the hardware has to monitor a sequence of 11 consecutive recessive bits on the CAN Rx signal."
I can think of two reasons why clearing of the bit is not happening:
1. These 11 bits are not received for some reason 2. Something is wrong with the hardware set up
I don't know why the 11 bits would be required. Only reason I can think of is that it has something to do with the bit timing or baud rate. The processor is expecting nothing on the bus for a defined time period. Therefore I assumed that these 11 bits have to be flanked by dominant bits because otherwise the processor does not know when the time starts and ends. I'm just guessing because otherwise it doesn't make much sense.
The other possibility is that there is something wrong with the hardware set up. To make CAN work I have to re-map the CAN pins because of the way the transceiver chips are connected. I think I have done this right but it would be great if somebody has a set-up that works so I can compare. As I mentioned the CAN ports work in loopback mode.
So, enough with the thinking: get measuring! Get out your oscilloscope and check what's on your RX pin. Is your CAN transceiver even enabled? What's the actual state of the RX line (from transceiver to CPU)?
Is there any other CAN device on that CAN bus in this case? Is the bus properly terminated, i.e. does it have recessive state while no device is transmitting?
Problem solved. The set up of the Rx pin was causing the problem. It is working if the Rx pin is configured as a floating input. I had it configured as an input with pull down.
Nothing special is required for the synchronisation. It just looks for an idle bus before switching from initialisation mode to normal mode.