> bus off is mostly gone, even if it still happens sometime
"Bus off" is a very serious error. CAN retries transmissions in hardware when it detects errors. It has to get 15 or 32 hard errors in a row before it goes "Bus Off". That's not something you should ignore.
CAN is a three-wire bus. Make sure you have a common ground connection between all of your CAN devices. A lot of people get this wrong and it can cause problems from "random" up to "exploding chips".
You're getting reception working. I can't see your setup from here, but you're implying there's only two devices on the CAN bus, the "Peak" whatever and the MCF. Is that correct? If that IS correct then the MCF CAN module must be transmitting in order to receive. That's because when one device transmits a CAN message, there's a one-bit "ack slot" in the message. At least one other device on the bus has to transmit a "Dominant bit" (meaning it has to drive the bus) during that bit time to tell the transmitter that the message has been received.
So you should set up continuous transmission from the "Peak" device and monitor the RX and TX pins on the MCF CAN transceiver. You should see it transmitting the ACK bits. If that is happening then the CAN module, the transceiver and the MCF pin programming are all set up properly.
If you have three (or more) devices on the bus then the OTHER device might be driving the ACK bit, and so this test doesn't show much. But you should still look for that ACK bit on the MCF.
So please do all that first and report back on it. And please detail fully what your test setup is and how many CAN devices are on the bus.
If it isn't sending the ACK, then maybe you have the port setup programming wrong and the CAN TX pin on the MCF isn't set up properly - maybe it is set up as a GPIO and not connected to the CAN module.
The next thing that goes wrong is that the FlexCAN port won't be able to finish initialising (specifically can't get out of the config state) if the CAN bus isn't idle. This can happen if it isn't terminated. Make sure you're using the same test setup that can receive properly when you're transmitting.
You're probably seeing the second attempted transmit not return because the first one hasn't completed.
> [ 68.920000] flexcan_start_xmit(): entering
> [ 68.920000] flexcan_start_xmit(): can_id = 00680000
> [ 68.930000] flexcan_start_xmit(): can_ctrl = 0c080000
I can't see your code, so I have no idea what "can_id" is. There are no registers in the MCG54418 Reference Manual with that name. I'm guessing that's the second word in the message buffer.
How have you got CANMCR programmed?
That CANCTRL register has PRESDIV=12, PSEG1=1, PSEG2=0, PROPSEG=0. That's illegal. Nobody sets it up like that. That takes Fsys/2 and divides it by 13 and then has 5 Quanta in a bit, or one bit is the system clock divided by 65. Do you have a 32MHz clock perhaps?
If you read "33.3.21 Protocol Timing", and specifically "Figure 33-19. Segments within the Bit Time" it says the minimum value for the above sums is EIGHT and not FIVE as you have. If you're running 32MHz then you should have 8 or 16 quanta and have PRESDIV set to 7 or 3 as appropriate to divide by 8 or 4. That gets you an exact 500000 bits/second.
That might explain why the poor thing can't receive properly and can't transmit. It can't get around to all the work it has to do within a bit with too few clocks. It needs at least 8 clocks per bit to get everything done.
How are you getting those PSEG values? I thought the driver or the "ip" program was meant to select a valid set of numbers given the system clock and the requested baud rate.
> esr before flexcan_start_xmit() return
> [ 68.930000] flexcan_start_xmit(): esr = 00000080
That shows the CAN bus is idle then, and without any errors (yet). What does it show later?
This is how I'm setting the PSEG values up - this is Linux 2.6, so it has probably changed ... where have the advanced editing options gone? I can't insert code any more???
Tom
