MSCAN experts, please help.

[Bloodhound]

Hi All,

I'm getting a little frustrated here with what should be something so simple.

I am at the stage of testing the CAN circuit on a new product but I am not having much success.

I've given up on Rx'ing a CAN message, instead I thought I'd simply try to send something...well, I can send but there is something very odd happening.

Problem#1 - When I set the Tx Buffer up, IDR0, DLR, DSR0 etc it appears nothing is actually being moved in to the buffer. You can see in the Assembly window (in the attached screen shot), there has been data moved in to the DSR0 - DSR7 but it still shows as $AD on the memory trace.

Problem#2 - When it does put the message in the Tx Buffer (maybe it is filling with $AD as the memory dump shows?) once the message is in there the MSCAN is sending the same thing over and over very fast (I am not in a loop doing this either) and then it shows all sorts of Tx error flags are set. The meaning of which is not very clear in the documents as to what causes the flags to set.

Any help would be much appreciated.

Thanks,

Ross

[Sten]

Without addressing the rest of your questions; the symptom that the message seems to be transmitted repeatedly suggest that the message is not accnowledged. Do you have an other node on your CAN-bus with the ability to accnowledge the message? Also the terminating resistance is important, without it the bus will not work and a transmitter will try to transmit over and over again until it goes off bus.

[Bloodhound]

There is another node on the bus, but, it is only there to provide the correct termination resistance, it's not going to ack what the HC08 is sending.

I've scoped the CAN Tx / Rx pins on the HC08 and they do have nice clean data on them. (both go via a MCP2551). Also, scoping the CAN bus the signals look nice too (nothing like what unloaded CAN signals look like). So I am pretty sure hardware wise everything should be ok.

Thanks,

Ross

[Sten]

Every CAN message must be acked by at least one other node on the bus, otherwise the transmitter will retry until it goes off-bus.

Sten

[Bloodhound]

That seems odd?

I could picture a scenario where for example the 'master' node might transmit a message of say the temperature for all other nodes to listen to but if none of them ack the transmission then the master node will retry endlessly? Even though the master node does not need any response back to continue on with what is might be doing.

Cheers,

Ross

Message Edited by Bloodhound on 2007-11-22 09:02 AM

[Bloodhound]

Well, I've gone back in to testing recieving a message on the HC08.

If I just send 'one' message on the CAN bus for the HC08 to Rx, the CRFLG register is getting set as follows:

RWRNIF = 1, MSCAN08 has gone into receiver warning status.

RERRIF = 1, MSCAN08 has gone into receiver error passive status.

RXF = 0, The receive buffer is released (not full).

But I cannot find anywhere in the Moto docs where they describe what causes these bits to be set? It's obviously indicating something is messed up for the Receive Error Counter to exceed 96 from just one message sent over the CAN bus.

Cheers,
Ross

[Sten]

Quote from the CAN-standard about the ACK Field of a CAN message:

The ACK FIELD is two bits long and contains the ACK SLOT and the ACK DELIMETER. In the ACC FIELD the transmitting station sends two 'recessive' bits.

A RECEIVER which has received a valid message correctly, reports this to the TRANSMITTER by sending a 'dominant' bit during the ACK SLOT (it sends 'ACK').

This means that there must always be at least two working nodes on a CAN-bus for anything to work, one transmits and the other to send the ACK. But the receiver does not have to do anything with the message it receives, nor do anything by software to send the ACK; the CAN controller will send the ACK automatically when it receives a valid messsage.

Message Edited by Sten on 2007-11-22 08:21 AM