Lines Matching full:can
3 CAN Shell
13 The CAN shell provides a ``can`` command with a set of subcommands for the :ref:`shell <shell_api>`
15 interface without having to write a dedicated application. The CAN shell can also be enabled in
16 existing applications to aid in interactive debugging of CAN issues.
18 The CAN shell provides access to most CAN controller features, including inspection, configuration,
19 sending and receiving of CAN frames, and bus recovery.
21 In order to enable the CAN shell, the following :ref:`Kconfig <kconfig>` options must be enabled:
28 ``can`` command:
30 * :kconfig:option:`CONFIG_CAN_FD_MODE` enables CAN FD specific subcommands (e.g. for setting the
31 timing for the CAN FD data phase).
32 * :kconfig:option:`CONFIG_CAN_RX_TIMESTAMP` enables printing of timestamps for received CAN frames.
33 * :kconfig:option:`CONFIG_CAN_STATS` enables printing of various statistics for the CAN controller
34 in the ``can show`` subcommand. This depends on :kconfig:option:`CONFIG_STATS` being enabled as
36 * :kconfig:option:`CONFIG_CAN_MANUAL_RECOVERY_MODE` enables the ``can recover`` subcommand.
38 …e :zephyr:code-sample:`hello_world` sample for the :zephyr:board:`frdm_k64f` with the CAN shell and
39 CAN statistics enabled:
48 interact with the shell. The CAN shell comes with built-in help (unless
49 :kconfig:option:`CONFIG_SHELL_HELP` is disabled). The built-in help messages can be printed by
50 passing ``-h`` or ``--help`` to the ``can`` command or any of its subcommands. All subcommands also
54 All of the CAN shell subcommands take the name of a CAN controller as their first argument, which
55 also supports tab-completion. A list of all devices available can be obtained using the ``device
57 all use the device name ``can@0``.
62 The properties of a given CAN controller can be inspected using the ``can show`` subcommand as shown
63 below. The properties include the core CAN clock rate, the maximum supported bitrate, the number of
69 uart:~$ can show can@0
98 The CAN shell allows for configuring the CAN controller mode and timing, along with starting and
99 stopping the processing of CAN frames.
102 The CAN controller mode and timing can only be changed while the CAN controller is stopped, which
103 is the initial setting upon boot-up. The initial CAN controller mode is set to ``normal`` and the
110 The classic CAN bitrate/CAN FD arbitration phase bitrate can be configured using the ``can bitrate``
115 uart:~$ can bitrate can@0 125000
118 If :kconfig:option:`CONFIG_CAN_FD_MODE` is enabled, the data phase bitrate can be configured using
119 the ``can dbitrate`` subcommand as shown below. The bitrate is specified in bits per second.
123 uart:~$ can dbitrate can@0 1000000
130 It is also possible to configure the raw bit timing using the ``can timing`` and ``can dtiming``
137 The CAN shell allows for setting the mode of the CAN controller using the ``can mode``
142 uart:~$ can mode can@0 loopback
145 The subcommand accepts multiple modes given on the same command line (e.g. ``can mode can@0 fd
146 loopback`` for setting CAN FD and loopback mode). Vendor-specific modes can be specified in
152 After the timing and mode has been configured as needed, the CAN controller can be started using the
153 ``can start`` subcommand as shown below. This will enable reception and transmission of CAN frames.
157 uart:~$ can start can@0
158 starting can@0
160 Prior to reconfiguring the timing or mode, the CAN controller needs to be stopped using the ``can
165 uart:~$ can stop can@0
166 stopping can@0
171 In order to receive CAN frames, one or more CAN RX filters need to be configured. CAN RX filters are
172 added using the ``can filter add`` subcommand as shown below. The subcommand accepts a CAN ID in
173 hexadecimal format along with an optional CAN ID mask, also in hexadecimal format, for setting which
174 bits in the CAN ID are to be matched. Refer to the interactive help output for this subcommand for
179 uart:~$ can filter add can@0 010
180 …adding filter with standard (11-bit) CAN ID 0x010, CAN ID mask 0x7ff, data frames 1, RTR frames 0,…
183 The filter ID (0 in the example above) returned is to be used when removing the CAN RX filter.
185 Received CAN frames matching the added filter(s) are printed to the shell. A few examples are shown…
205 * ``B``: The frame has the CAN FD Baud Rate Switch (BRS) flag set.
206 * ``P``: The frame has the CAN FD Error State Indicator (ESI) flag set. The transmitting node is
212 * ``010``: The standard (11-bit) CAN ID of the frame in hexadecimal format, here 10h.
213 * ``00000010``: The extended (29-bit) CAN ID of the frame in hexadecimal format, here 10h.
217 * ``[8]``: The number of frame data bytes in decimal format, here a classic CAN frame with 8 data
219 * ``[08]``: The number of frame data bytes in decimal format, here a CAN FD frame with 8 data
231 timestamp from the free-running timestamp counter in the CAN controller.
233 Configured CAN RX filters can be removed again using the ``can filter remove`` subcommand as shown
234 below. The filter ID is the ID returned by the ``can filter add`` subcommand (0 in the example
239 uart:~$ can filter remove can@0 0
245 CAN frames can be queued for transmission using the ``can send`` subcommand as shown below. The
246 subcommand accepts a CAN ID in hexadecimal format and optionally a number of data bytes, also
252 uart:~$ can send can@0 010 1 2 3 4 5 6 7 8
253 enqueuing CAN frame #2 with standard (11-bit) CAN ID 0x010, RTR 0, CAN FD 0, BRS 0, DLC 8
254 CAN frame #2 successfully sent
259 The ``can recover`` subcommand can be used for initiating manual recovery from a CAN bus-off event
264 uart:~$ can recover can@0