CAN bus off recovery

[CharlesO]

Hi,

I am using the MC9S12C64 micro with a TI HVD1050 CAN driver chip and during ESD testing I can get the CAN controller to go into bus-off state but it then takes around 60 to 90s to come right. When running the test my device is continuously sending CAN messages to report sensor values and the values eventually start coming through again, but after quite a long delay. The data is being received by a PC program via a Peak PCAN interface.

The firmware is detecting that the CAN controller has gone into bus-off state and I have tried making it re-initialise the CAN controller, but that does not seem to change the behaviour. I know that the mmicro and CAN driver firmware is running OK during this time as it is flashing an LED to indicate the bus-off state. As far as I can make out (from the datasheet and extensive searching on the 'net) the S12MSCANV2 should recover from bus-off after 128 occurrences of 11 consecutive recessive bits and as the bus seems to be going idle during this period I would expect it to recover in about 5.6ms (bus is running at 250kpbs).

Has anyone seen this before and can suggest some ideas on how to get it to recover more quickly?

Thanks.

regards,

Charles

[kef]

On S12C recovery from bus-off is automatic, no special actions are required.

Who actually tells you there was bus-off? Is it MCU flashing some LED to indicate this error, or indeed PCAN software on PC? Isn't it PCAN HW/SW that fell down for 60-90s during ESD test? 

[CharlesO]

Thanks for your comments, kef.

>On S12C recovery from bus-off is automatic, no special actions are required.

That was the conclusion I had come to, but it is nice to have it confirmed.

>Who actually tells you there was bus-off?

>Is it MCU flashing some LED to indicate this error, or indeed PCAN software on PC?

The MCU is detecting the bus-off condition using the CAN error interrupts and then flashing the LED to indicate this condition.

>Isn't it PCAN HW/SW that fell down for 60-90s during ESD test?

It could be, but doesn't seem to be. The PCAN is configured for auto-recovery from bus-off and if I try getting the PC to send a CAN message while the MCU is still reporting bus-off (after the ESD spikes) then the CAN bus goes busy for a while with the same pattern that you get when the other end of the link is not responding (i.e. indicating that the PCAN is trying to send, but not getting any response from the MCU).

- Charles

[kef]

> >Isn't it PCAN HW/SW that fell down for 60-90s during ESD test?

> It could be, but doesn't seem to be. The PCAN is configured for auto-recovery from bus-off and if I try getting the PC to send a CAN message while the MCU is still reporting bus-off (after the ESD spikes) then the CAN bus goes busy for a while with the same pattern that you get when the other end of the link is not responding (i.e. indicating that the PCAN is trying to send, but not getting any response from the MCU).

I don't think this proves that your controller is the node that fails. I think you need to eliminate any unreliable-by-default PC stuff. It easily could be MCU inside PCAN interface, that gets stuck/reset and waits for firmware to be redownloaded from host. 60s? Easily. To be sure I would wire my own node to the bus to see what's happening. One type of CAN dongle from robust supplier, we were using, was loosing messages. Another one looses the ground when I just switch table-top lamp. Either PC reports it lost connection with the dongle, or, worse, it doesn't tell anything but won't receive any message until reconnected.

[CharlesO]

We've been thinking along the same lines and plan to try a different CAN interface to the PC.

[CharlesO]

I am still trying to solve this issue, but have managed to find out a lot more about the problem.

When the MC9S12C64 is not able to send on the CAN bus (after the ESD spike) it is continuously getting CAN error interrupts about every 2 or 3ms with TSTAT=TxERR, then TSTAT=Bus-off then TSTAT=TxOK - this carries on for around 10 to 90 seconds and then there is a transmit buffer empty interrupt and it comes right. I know that the CAN bus is OK during the period of CAN error interrupts because another CAN node on the bus is able to talk to the PC CAN interface that is on the bus.

Anyway, if anyone has seen anything similar and has some ideas please let me know.

Thanks,

Charles

[kef]

It's interesting.

Did you check supply voltage? Maybe for some weird reason Vdd stays somewhere between 5V and 3V, allowing MCU to run, but upsetting 5V CAN driver? Unlikely it would take so long.

Isn't MCU reset during ESD test?

How is MSCAN clocked? CLKSRC is set up for directl clocking from crystal oscilator/ext.clock, or is it set up to clock MSCAN from PLL? I would make bus clock visible on ECLK pin and check if it is stable. 90s should be enough to connect oscope probe.

I hope you made service request for this issue. What did Freescale suggest?

[CharlesO]

This is a bit late (a year later!), but I meant to post an update on this question so anyone reading it in the future knows where I got to on this issue.

I didn't come to any great conclusion about what was happening, but we did find two things -

1. The ESD testing that the technician was doing was at a higher voltage than required for the final testing done by the lab. I don't think that the problem happened with lower voltage spikes.

2. We moved to a CAN transceiver with higher ESD spec.s (NXP TJA1051T).

The product passed the tests and we haven't had this problem in normal use.