How to port the SPE CAN demo to current SPE SDK on ORIN devkit?

I am currently using the ORIN devkit and I wish to control a CAN peripheral within the SPE(ARM R5 core) firmware.
Unfortunately, the current SPE SDK does not include a CAN demo. So, I have decided to attempt porting a previous CAN demo into my project.
Regrettably, my initial attempts at porting the CAN demo have not been successful. I am seeking guidance on identifying where I went wrong and how to debug the issues.
I described the detailed step that I did and my question.

1. Development env

2. CAN demo porting

  1. Hardware Setting

    • The two CAN transceivers were connected to the ORIN so that CAN messages could be transmitted to each other.
    • I checked that CAN messages transfered each other successfully.
  2. Port the CAN driver and demo app

    • Copy the can app and driver from the previous CAN demo code
    • Insert code to enable demo app in main.c and build successfully
  3. Pinmuxing updates in the bootloader

    • ${L4T}/bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi
    • Update the same settings as tested in section 1)
  4. gpio configuration update in the bootloader

    • ${L4T}/bootloader/tegra234-mb1-bct-gpio-p3701-0000-a04.dtsi
    • delete the following code
     TEGRA234_AON_GPIO(AA, 0)
     TEGRA234_AON_GPIO(AA, 1)
     TEGRA234_AON_GPIO(AA, 2)
     TEGRA234_AON_GPIO(AA, 3)
  1. firewall setting update in the bootloader
    • ${L4T}/bootloader/tegra234-mb2-bct-scr-p3701-0000-override.dts
    • insert the following code
     reg@2125 { /* CLK_RST_CONTROLLER_AON_SCR_CAN_0 */
          exclusion-info = <3>;
          value = <0x30001410>;

3. result

  • Jetson linux boot fail
  • boot message
[   11.975156] random: crng init done
[   12.086293] CPU:0, Error: aon-fabric@0xc600000, irq=35
[   32.325596] **************************************
[   42.456502] vdd-12v-sys: disabling
[   51.525244] CPU:0, Error:aon-fabric, Errmon:1
[   51.525251] 	  Error Code		: TIMEOUT_ERR
[   51.525253] 	  Overflow		: Multiple TIMEOUT_ERR

4. My question

  1. Is there a setting I missed or wrong?
  • For example, the previous CAN demo instruct to modified the following SCR.
  • I update only CLK_RST_CONTROLLER_AON_SCR_CAN_0. If other SCRs need to be modified in ORIN, what is the correct value of this SCR reg?
  1. Does Nvidia have plans to release SPE SDK DEMO that supports CAN in ORIN?

For CAN access, you are right. So far, it’s not supported in SPE package yet.

For your issue, have you ever disabled CAN in Linux side? I’m a little confused by the error you pasted. You just changed those settings, and keeps original SPE firmware?


Thank you for your reply.

have you ever disabled CAN in Linux side?

  • When I wrote this post, I didn’t disable the mttcan 1/2 device trees because I wasn’t using the CAN module on the Linux side (I hadn’t loaded the CAN Linux kernel modules).
  • However, I tested my firmware again after disabling the mttcan 1/2 device trees.
  • As a result, the test failed (Jetson Linux hung on the GNOME DESKTOP during boot), but the boot logs had changed.
��Transmited message from CAN 0
��WARNING: clock_disable: clk_power_ungate on gated domain 35 for gpusysclk
WARNING: clock_disable: clk_power_ungate on gated domain 35 for gpc1clk
WARNING: clock_disable: clk_power_ungate on gated domain 35 for gpc0clk
��[   12.165090] ALSA device list:
[   12.168897]   No soundcards found.

You just changed those settings, and keeps original SPE firmware?

  • No. I flash my custom firmware in order to test the can demo.
  • When I use the original SPE firmware after changing those setting (pinmux, scr…), Jetson Linux boots successfully.
  • The custom firmware is a combination of SPE_SDK_34.1.1 xavier CAN demo code based on SPE_SDK_35.4.1 for orin.

I do not see any error from Jetson_Orin_boot_fail.log
Last lines:
[ 16.768815] IRQ 122: no longer affine to CPU11
[ 16.773947] CPU11: shutdown

Ubuntu 20.04.6 LTS ubuntu ttyTCU0

ubuntu login:

and it looks good.

You can add more print in SPE firmware to confirm it keeps running.
In addition, in SPE firmware, you can also add some code to read CAN registers, to make sure the register-level access is good.


Thank you for your replay.
As your advice, I checked whether the CAN register is accessible.
The conclusion was that accessing the CAN register caused the entire system to hang and rebooted after a while.I think my firmware can’t access the register.
The test code and results are attached to the following.
Would you tell me the way to check why my firmware can’t access the register?

test code

if (!ttcan)
	printf("CAN TX handle is null\r\n");
	printf("CAN TX handle : CAN%lu, Base reg : %08lx\r\n", ttcan->id, ttcan->base);

/* Reset CAR */
result = tegra_clk_reset_pulse(ttcan->rst, 1);
if (result)
	printf("CAN%lu reset CAR fail : %d\r\n", ttcan->id, result);
	printf("CAN%lu reset CAR OK\r\n", ttcan->id);

/* Enable Access */
printf("CAN%lu Enalbe access reg prev: %08lx\r\n", ttcan->id, ttcan_xread32(ttcan, ADDR_M_TTCAN_CNTRL_REG));
printf("CAN%lu Enalbe access reg result: %08lx\r\n", ttcan->id, ttcan_xread32(ttcan, ADDR_M_TTCAN_CNTRL_REG));


CAN TX handle : CAN0, Base reg : 0c310000
CAN0 reset CAR OK

← after print out, all system hung…

Would you tell me the way to check why my firmware can’t access the register?
(the value of reg@2125 SCR is right?)

No one has given me an answer for a long time.

Sorry for late reply.

You can try following. (All steps below are based on default BSP.)

  1. Do not access CAN1 (base address 0xc310000) right after SPE firmware’s up.
  2. When kernel’s up, run following commands:
    modprobe can;modprobe can_raw;modprobe mttcan;
    and then run busybox command:
    busybox devmem 0xc310000
    to make sure the CAN register can be accessed correctly.
  3. Send a message to SPE firmware, and CAN register access from SPE side should be good then.
  4. No update of CAN in Linux side then to prevent confliction.

Since CAN is not formally supported in SPE firmware so far, and you can take above instructions as a workaround.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.