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.
For example, the previous CAN demo instruct to modified the following SCR.
: CLK_RST_CONTROLLER_AON_SCR_CAN_0, CLK_RST_CONTROLLER_CAN1_SCR_FMON_0, CLK_RST_CONTROLLER_CAN2_SCR_FMON_0, AON_NOC_CAN1_BLF_CONTROL_REGISTER_0, AON_NOC_CAN2_BLF_CONTROL_REGISTER_0
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?
Does Nvidia have plans to release SPE SDK DEMO that supports CAN in ORIN?
Hello, mw.kim:
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?
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.
Hello,
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");
else
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);
else
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));
ttcan_set_ok(ttcan);
printf("CAN%lu Enalbe access reg result: %08lx\r\n", ttcan->id, ttcan_xread32(ttcan, ADDR_M_TTCAN_CNTRL_REG));
result
CAN TX handle : CAN0, Base reg : 0c310000
CAN0 reset CAR OK
You can try following. (All steps below are based on default BSP.)
Do not access CAN1 (base address 0xc310000) right after SPE firmware’s up.
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.
Send a message to SPE firmware, and CAN register access from SPE side should be good then.
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.