Listen-only CAN on 908AZxxA

[Sten]

I would need to make an automatic bitrate detection for a set of old hardwares built around the HC908AZ32A and HC908AZ60A controllers. I have already successfully done it on the newer, S12D-based hardwares, but it uses the MSCAN's Listen-Only Mode, and that mode does not exist in the older MSCAN08 on the 908AZ-controllers.

On the S12D I have done it so that when the system starts, it puts the CAN-interface in Listen-Only Mode and then scans though the different bitrates until a legal frame is received, after which the bitrate is locked and the Listen-Only Mode is cleared. I think that the Listen-Only Mode is needed so that a node, that is currently scanning on a faulty bitrate, does not mark frames on the bus as errorframes.

Do anybody have a solution how to do it on a HC908AZ without changing the hardware?

[Lundin]

No idea how to do it without hw changes. Too bad they didn't mux the CAN pins with an I/O pin or you could have measured the baudrate, rather that using trial/error as you describe in the S12 case.

On HCS12 you could save a lot of time by disabling CAN, enabling the I/O pin at the same location as the CAN port, measure the bit time, calculate baudrate and then enable CAN with the calculated baudrate. I've done the same with SCI once.

[Alban]

Dear People !

On the AZ32A, the msCAN pins are dedicated, so no I/O mutliplexable.

I don't know what you mean by not changing H/W as the S12 and HC08AZxxA and S12 are not pin to pin compatible.

If it's because you already have done the AZxxA PCB, you can get away by puting a bit of wire with a TIMer input capture and apply Lundin solution. It's what used to be done on some other simpler protocols.

Cheers,

Alban.

[Sten]

This message now comes on the wrong forum and under a wrong subject, sorry, but it is so closely related to the previous messages in this thread, that I want to continue here.

I've stumbled into something I can't explain, and would want to ventilate it with you guys out there: the S12D-system I mention in the original post do not work as expected. Example: I have a test system with two nodes, one of them starts on a fixed baudrate and tries to transmit frames and the other one is in listen-only mode and tries to detect the bitrate by scanning possibilities (250ms per baudrate, when a frame received the correct bitrate is found). Because no node is Acking the first node's frames, the second node should never receive a legal frame, and the system should never start. But it does, the second time the scanning node comes to the correct baudrate, it exits the listen only mode and the system starts.

The scanning node is based on a MC9S12D32VFUE, maskset 0M89C. The scannig routine works so that it first initialises the MSCAN to the first baudrate and listen-only and then takes it out of Init-Mode. 250ms later it puts MSCAN into Init-Mode again, change to the next baudrate and exits Init-Mode. Continues like that until a receive-interrupt is got, at which point the baudrate is locked and listen-only set to zero.

Does anybody have some idea why the system starts, why the node that is in listen-only mode suddenly can put out an Ack-bit, or why it suddenly can receive a legal frame althoug no other node exists on the bus giving the Ack-bit. I have looked at the bus with an oscilloscope and the transmitting node is sending frames back-to-back for about 500..800ms at which point the system starts and the bus looks normal.

thanks for any ideas

Sten

[Lundin]

Although this is a bit far-fetched, I encountered something similar in my own mscan driver. This is my own bug fix notes for my driver:

"Upon CPU reset, or if the can_InitHardware() function is called twice
in a program, the MSCAN hardware will be forced into initialization
mode which causes the TXCAN pin to go high (recessive). To avoid this,
Freescale recommends that MSCAN is brought into sleep mode before any
hardware settings are changed. "

Are you setting both SLPRQ and INITRQ before entering init mode?

Apart from that, I'd read through every errata regarding MSCAN. I know at least that the S12Dx128 has several suspicious erratas that could be the cause.