Example Path: examples/PlatformSpecific/SAME70/MODM7AE70/CAN_Simple

Supported Platforms: MODM7AE70

A very simple CAN example to send and receive packets:

Creates a CAN receive task
Serial port menu with options to send, receive, manipulate RTR filters
CAN communication requires 2 CAN devices. As a test you can send/receive by jumpering the CAN pins together

WARNING – MOD-DEV-70 DIP switch configuration (default P2[6] CANRX1): On the MOD-DEV-70 development board, the MCAN1 RX pin (P2[6] / J2_6) routes through a DIP switch. In the OFF position the pin is pulled to ground through a 1 k resistor; in the ON position it is tied to VCC. Because the CAN controller interprets RX-low as a continuously dominant bus, leaving the switch OFF holds the controller in bus integration and the example will appear inert – transmitted frames never leave the TX FIFO and the receive task prints nothing. Before bench-testing this example without a transceiver (including the CANTX1<->CANRX1 jumper-loopback test mentioned above), set the J2_6 DIP switch to the ON (VCC) position. See the CAN_ErrorRecovery example's ReadMe for the full DIP-OFF / DIP-ON explanation.

Optional: routing CANRX1 to P2[23]:

If you prefer to route CANRX1 to P2[23] (CPU port PD28, Peripheral B mux) – for example, to free P2[6] for one of its other peripheral functions (TIOB8) or for GPIO use, or because your custom board brings CANRX1 out on a different header pin. The MCAN1 controller instance does not change; only the pin-function call moves.

To switch, in main.cpp comment out: P2[6].function(PINP2_6_CANRX1); and uncomment: P2[23].function(PINP2_23_CANRX1);

The underlying pin-function macro PINP2_23_CANRX1 is defined in platform/MODM7AE70/include/pinconstant.h.

The notes below describe the MOD-DEV-70 development board, which wires P2[23] through R10 (330 ohm) to the cathode of an LED whose anode sits at 3.3V. Other development boards may load P2[23] differently or not at all – consult the schematic for your specific board before relying on the behavior described here.

CAUTION – on the MOD-DEV-70, R10 must be removed for reliable CANRX1 operation without a transceiver: If you intend to bench-test this example by jumpering CANTX1 to CANRX1 (or otherwise running without a CAN transceiver actively driving the pin), the MOD-DEV-70's R10 must be removed first. With R10 and the LED in place and no transceiver driving the pin, the LED clamps the pin to roughly 3.3V minus the LED forward drop (around 1.3V), which lands in the SAME70 input indeterminate zone. The MCAN controller will not complete bus integration and the example will appear inert – no traffic moves and the receive task prints nothing. Remove R10 (or lift the LED) before running the loopback / no-transceiver test on P2[23].

Free CAN-RX activity indicator (MOD-DEV-70, transceiver attached):

On the MOD-DEV-70, if R10 and the LED are left in place and a CAN transceiver is wired to P2[23], the LED becomes a free CAN-RX activity indicator. Each dominant bit on the bus pulls the pin low and draws roughly 4 mA through R10 and the LED – well within any standard CAN transceiver RXD sink capability and with negligible effect on edge rates at 500 kbit/s. The LED lights or flickers with bus traffic and is off when the bus is idle. On other development boards this behavior depends entirely on what (if anything) is wired to P2[23].