How to debug SPE CAN Issues


I am trying to transmit and receive CAN using SPE.
but I have some issues with SPE CAN implementation.

first, I am trying running demo-sw according to Jetson Sensor Processing Engine (SPE) Developer Guide: Welcome.
my demo-sw is configured to receive can messages. and I modified device-tree (disable mttcan@c310000 in kernel), pinmux(tegra19x-mb1-pinmux-p3668-a01.cfg) and SCR(tegra194-mb1-bct-scr-cbb-mini-p3668.cfg) according to the guideline.

I send messages using CAN simulator like CANoe.
but it is not working.

I checked below,

  1. check RXD line which is from transceiver (NCV7344-3) : no problem.
    (I can see that CAN signal is received via RXD. 0-3.3V)
  2. check kernel device tree : no problem. (disabled]
    $cat /proc/device-tree/mttcan\@c310000/status
  3. check pinmux : no problem [pinmux is set according to the guideline]
    but…is it correct to check kernel pinmux setting for SPE??
    $sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep "can0"
  4. check secure control register : ??? HOW ???

there is CAN ack error in the CAN bus.
it means that there is no can controller which sends dominant level in ack slot when simulator send a message. so I think that CAN controller (mttcan) seems not to be activated.
but I can not figure out the reason.

please, let me know how to check pinmux and scr configuration are changed correctly. (and I also want to know what is SCR)

CAN-related information is located at rt-aux-cpu-demo/doc/
Generally, if you follows every step in that doc and connect the transceiver correctly, everything should work as doc mentioned.
Some debug tips.

  1. For pinmux checking, you can run tools like devmem to read the register directly in Linux side. For example, as doc mentioned, the register @0x0c303010 should be 0x400.
  2. For SCR, it’s register access control. If that’s not set correctly, the SPE firmware will crash when accessing CAN registers. You can add some debug code to make sure the register RW is good.
  3. You can check the pin signal with scope. Once the SPE execute transmit command, check whether the CAN TX pin can generate correct waveforms.
    3.1 no waveform, please check pins, either the pin is wrong, or pinmux is not configured correctly.
    3.2 only a pulse. most probably, transceiver is missed or bad.
    3.3 a series of pulse. it should work. If no correct data received, maybe the incorrect clock setting. You can start from low speed, like 500k.

hope that can help.


thank you for your tips! :)

  1. for pinmux, I used devmem to read the registers.
    and the result is correct.

    $sudo busybox devmem 0x0c303010 #0x000400
    $sudo busybox devmem 0x0c303018 #0x000458
  2. for SCR, I am so sorry.
    could you give me more detail information? how can I know accessing CAN registers is denied.

    I cannot see SPE debug messages when system is initialized.
    I assume that SPE messages fail to be printed because there is a lots of linux messages.

  3. I re-build demo-app to act as transmitter (transmit pre-defined message) and check the pins.
    there is no pulse signal on TXD pin. TXD pin is just high level.
    and as I mentioned above, I can see received pulse signal on RXD pin if I transmit some message using simulator. so I think that transceiver is okay.

according to 1(check pinmux), 3(check pin signal), I guess that there might some problem in setting can controller registers (because of wrong SCR?)… could you help me check this?

thank you so much.


  1. that means the pinmux is correct. In addition, you can enable the CAN in kernel side, and test whether it can work in Linux side, to make sure the pins are configured correctly. (Jetson/AGX Xavier CAN -
  2. SCR, I think you have to follow the setings in and make sure the device is flashed after the setting changes.
    You can capture the SPE log in a separated console. Refer to
    Jetson/AGX Xavier Tegra Combined UART -
    GitHub - NVIDIA/python-jetson: Python utilities for NVIDIA Jetson
    Adding more logs will help to check the issue.
  3. Still, check whether the CAN TX is issued, with some logs, or it fails during intialization.