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
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.