Problems with starting FlexCAN module

[Richmand]

 Hi. I hope anyone can help me with the following problem.

I want to build up a little CAN network and therefor I use a MCF52235. I'm using the FlexCAN connected to the pins SYNCA and SYNCB.

For the first tests I don't want to use interrupts I just want to initialize the registers and send some messages to a canalyzer.

And now the problem:

I initialized in this way.

- set the PASPAR register to secondary function (0xA0)

- then I disable the CAN module and start a softreset

- set the clock source to external oscillator (25MHz)

- initialize the bus frequency to 1Mbit/s

          PROPSEG = 8, LOM = 0, LBUF = 0, TSYNC = 0, SAMP = 1
          RJW = 4, PSEG1 = 8, PSEG2 = 8, PRESDIV = 1

- set the max message buffer to 16

- set global extended mask

- initialize all message buffers as inactive

- set message buffer 14 extended mask

- set message buffer 15 extended mask

- set specified message buffers to RX or TX with individual identifiers

- then another softreset

- and the last point is to set the FlexCAN module in normal mode.

I debug with the Abatron BDI2000 and when I look into register values, then every initialization was correct, but when I connect my system to canalyzer an write a little programm to send some data, nothing happens.

The data are written to the specified message buffer with the start code 'transmit once' but the message isn't transmitted and the code remains 'transmit once'. Normally the message should be transmitted and the code should be set to 'inactive'.

I think I forgot something during initialization, but I don't know what. Is there anything else I need to initialize to start FlexCAN module?

[JulienP]

Hello sir,

I'm running into quite the same problem, but in my case the data are transmitted (I can see it using a Peak System probe) but the register remains in write state, so the uC is transmitting for ever.

Have you fixed your bug, and how have you fixed it?

[TomE]

Do you have any RECEIVING devices on the CAN bus?

There has to be a transmitter and (at least one) receiver. Part of the CAN protocol is that the receiver drives one bit in the CAN message as an "ack" to say the message was received OK. If there's nothing connected on the bus generating that signal, then I think the transmitter keeps retrying until its error count runs out.

See the "ACK Slot" in the following:

http://en.wikipedia.org/wiki/Controller_area_network#Base_frame_format

See the details in this:

http://www.semiconductors.bosch.de/media/pdf/canliteratur/can2spec.pdf

Your CAN Analyser pod might give you the option of having it ack the message.

[cpan]

I'm facing the same issue on the MPC5607B; after i activate the message buffer (0xC code) it remains in 0xC state and it does not recover to inactive state. Curious is that in loopback mode the transmission works fine. Did anyone else figured it out what's the root cause of this behaviour?

I'm only using one node on the network, but the transmit does not happen at all (nothing seen on the osciloscope and the error counters remain 0), so this is not the cause i believe. Tried lower fBit frequencies with both PLL and fxosc with no results.

[TomE]

> Did anyone else figured it out what's the root cause of this behaviour?

There's a huge number of completely different ways for CAN to fail to work.

One problem you'll run into with your setup was the one I suggested for the post I was responding to, which was:

 

There has to be a transmitter and (at least one) receiver.

You're trying to use a single transmitter. That can't work, after you get over the other problems...

> but the transmit does not happen at all (nothing seen on the osciloscope

That's a different problem, one of many possible.

> and the error counters remain 0),

The error counters don't increment when there's no ACK to a transmit. This is a documented specific exception to the incrementing of the error counters. It is difficult to find though - it is in the original Bosch specification document - follow the link on Wikipedia.

Is the transceiver enabled? There's usually a GPIO pin on the CPU connected to the transceiver, and that pin has to be programmed as an output and set the the right value.

Is the controller sending data to the transceiver? If not then the pins on the CPU may be in the wrong mode. Depending on the CPU they may need to be reprogrammed from being GPIO pins to being CAN pins.

Tom