I am using a 9S12XEQ384 and a 9s12DG256 with the same code for CAN initialisation at 500K baud and processing interrupts. Both processors do the same as far as CAN retry.
The problem I want to solve is that sometimes I can upset the bus and it will retry a transmission about 150us after the last failure to send. This never gives the bus any chance to send any other messages. It never goes buss off. From what I understand it should leave the bus alone for around 2.8ms.
I am trying to abort the CAN messages I have pending, but I don't think my processor should take over the bus.
Is there something in my initialisation that may cause this. Is there an auto off bus recovery I am missing?
I can see the transmit and receive error counters go up to about 130 to 135 when the above happens. Should it not get to 254 and go bus off?
it is an alchemy. However,...
Usually we have met following issues.
1) There are incompatible CAN interface ICs used for physical CAN bus. Only devices with the same electrical and timing characteristics are able to communicate.
2) Wrong communication speed design.
3) Wrong SW approach. (I have attached SW examples which can help you to compare or test the system)
4) Have you tried to use CAN in loopback mode to check SW?
5) Wrong PCB design. There could be some EMI which affect CAN bus. Please check by oscilloscope signals at CAN bus and also at MCU’s CAN pins.
reference manual - MC9S12XEP100
register - CANCTL1
bit - BORM
Bus-Off Recovery Mode — This bit configures the bus-off state recovery mode of the MSCAN. Refer to
Section 16.5.2, “Bus-Off Recovery,” for details.
0 Automatic bus-off recovery (see Bosch CAN 2.0A/B protocol specification)
1 Bus-off recovery upon user request
When I am not able to detect error correctly the standard approach of mine to detect an error is following:
1) loopback mode
2) 2 nodes at the same MCU connected by R/diode described (no interface IC)
3) No interface solution from item 2 between two devices
4) Interface IC solution