Transmitting CAN messages and ignoring ACK with MCP2515

[HwAoRrDk]

I have a need to put together a test/simulation setup for sending CAN messages on a bus. The bus will consist solely of the simulating transmitter and one other receiving node (the DUT). However, the receiving node is designed to be a passive listen-only node, and thus will never ACK any of the messages it receives.

The test setup I was thinking of putting together would consist of an Arduino board with a CAN shield that uses an MCP2515 controller. I have been looking the MCP2515 datasheet, but I cannot seem to see an explicit way of telling it to ignore when a transmitted message goes un-ACKed. Otherwise, I believe that if I just went ahead and started sending out messages, it would not only continuously try to re-send the unacknowledged messages, but also after a short period it would start sending error frames and then eventually go to bus-off mode and stop. Obviously not very useful for my situation.

Can I use the 'one-shot' mode for my needs? I gather this turns off the retry mechanism, but will it result in complete messages being transmitted on the bus? That is, will my passive-listening DUT node still receive them as complete, error-free frames?

Also, how rigorous do I need to be with bus termination in a small test setup? The MCP2515 shield has built-in termination, but my DUT does not have any, as it is designed to only be a spur node on a bus with termination already existent at both ends. Should I just whack a resistor on a breadboard, have the shield connected to the breadboard, and put my DUT connections just before the resistor? Also, how critical is the exact resistor value? I don't think I have any 120R resistors, but I can probably series/parallel some up for something close (maybe ±10R).

[Chriss]

Hi!
For the termination resistor.
I was tried several setups on can bus, actully in some car diagnostic and flashing tools for ecu like 120+- 5% and also with or without resistor and everything was workink properly.
The ACK I'm not sure also what will happen.

May I ask you what kind of simulator you make?
I also thinking to make for me a can simulator for use in my job.
I would actually connect a diagnostic tool to the simulator and send some msg to the simulator....
Sorry I really don't want to hijack your post.
I'm just curious and interested in diy can simulator.

My best regard.

Sent from my GT-I8260 using Tapatalk

[MosherIV]

Hi

Not familiar with MCP2515. Just speed read (cursry scanned) the data sheet.

Have you tried 'one shot mode'?
The data sheet says that it will only send the message once regardless of arbitration loss or frame error.

Hope that helps.

[max_torque]

Just put a "dummy" second device on the bus, which never transmits data onto the bus, and have that one in "normal" mode, that way you'll get the ACK the CAN standard requires.

[Jeroen3]

Most CAN controllers have a bit to disable automatic retransmit. You shouldn't normally do this, since corrupted frames also do not get retransmitted, but in your case it might be the way to go.
I think Microchip calls this One Shot, but you should try it.

[HwAoRrDk]

I tried configuring the MCP2515 to use one-shot mode, but I'm not having any success.

When I send a message, it 'fails' - I have transmit interrupts enabled (TXnIE) to issue an interrupt on the INT pin upon successful transmission, and it never occurs - and I have to clear the TXREQ flag before attempting to send another message. But, I was expecting that.

So I hooked up a logic analyser to the CAN_L to inspect what's actually going out on to the bus (albeit there is no bus right now - nothing is connected to the CAN shield yet), but I'm not seeing a proper frame. All I see for every transmission is a brief 4 microsecond dominant low pulse spanning two bits (bus speed is 500kbps). This kind of makes sense, as the ID of the test message I'm using is 0x201, so if I'm correct in my thinking, the frame should actually start with two dominant bits. But it seems to just give up after trying to transmit the first recessive bit of the ID.

I was under the impression that with no other nodes on the bus it would fail only at a later stage when the message goes un-ACKed. So I'm not sure what's going on here.

Just put a "dummy" second device on the bus, which never transmits data onto the bus, and have that one in "normal" mode, that way you'll get the ACK the CAN standard requires.

I don't have anything else to hand I can put on the bus to ACK the messages. Should've bought two CAN shields...

[HwAoRrDk]

Added some code to output the value of the relevant TXBnCTRL register after sending each message. It always has the ABTF and MLOA flags set (TXERR is not set), meaning that the message lost arbitration during transmission and was aborted.

I don't understand, why would it lose arbitration when there are no other nodes on the bus?

[HwAoRrDk]

Sigh... Well, if I actually connect a 'bus' of sorts that has termination, even if it's just a couple of jumper wires going to a 130R resistor (actually 3 * 43R) on a breadboard, now everything works as I expect it.

Logic analyser shows complete messages transmitted on the bus. Error flags still get set - ABTF and this time TXERR - but at least I have messages flowing, which is enough to suit my purposes!

So why, electrically, does an empty bus still need termination? And what causes a lone transmitter to lose arbitration with non-existent bus wiring?

[MadScientist]

 Because can transceiver are essentially wired -OR and the bus needs a pull-up , the resistor on low speed can systems ( <500 kHz ) isn’t really acting as a termination resistor

Dave