CAN_WAKE Problem

[AliHaeri]

Hi

The CAN_WAKE on the developer kit (Pin 1, J26) when toggled between 0 and 3.3V,
do not cause the Jetson to exit from deep sleep mode.
(which was entered by sudo systemctl suspend)

I checked the related registers. Here are the result:

Pinmux register 0x0c303048 → value : 0x58
GPIO register 0x0c2f1c80 → value : 0x1

Jetpack version: 4.6.1

Any help would be appreciated.

[kayccc]

Sorry for the late response, is this still an issue to support? Thanks

[AliHaeri]

Hi

Yes

Although I can communicate through CAN port, the CAN_WAKE pin does not function properly.

[AliHaeri]

Hi

I am waiting for a response

Thanks

[WayneWWW]

Please check the software feature listed in the developer guide.

We don’t enable CAN wake on jetson as wake up source.

[AliHaeri]

It means I should enable it in the Pinmux and reflash the jetson?

In the downloaded Pinmux file, the CAN_WAKE pin is set as a wake up source.

In ROW 221 of the Pinmux (CAN_WAKE pin), under Wake Pin column, “Yes” is selected by default.

[shgarg]

hi alihaeri,
Can you try toggling CAN DIN pin externally and check if system wakes up?

[AliHaeri]

Hi shgarg,

Yes I tried that.
I toggled the CAN0_RX between 0 and 3.3V with no success.

[shgarg]

Hi alihaeri,
May I know your external system connections from Jetson ? If you have connected CAN transceiver or something else?

[AliHaeri]

Hi

I tested the CAN_WAKE function on both Jetson TX2 Dev-Kit and on our custom carrier board.

On the Dev-Kit, there is no transceiver, and I did the test with loop-back mode turned on. When Jetson goes to deep sleep, it does not wake up when toggling CAN_WAKE pin.

On our custom carrier board, there is a CAN transceiver (SN65HVD230), connected to an External CAN bus.
Data is being transmitted and received on CAN-bus with no problem.
In this situation, I place the Jetson into deep sleep mode using:

sudo systemctl suspend

And when the CAN_WAKE toggles, I expect Jetson to wake up, but is does not.

[shgarg]

you should connect CAN_WAKE pin to transceiver. or connect other pin CAN_ERR, configure as GPIO , toggle then via CAN bus, system should wake.
If you transfer messages from transceiver via CAN_RX, Jetson will see activity, then also system should wake up.

[AliHaeri]

I did the same.

You suggested toggling CAN_RX in a previous post:

hi alihaeri,
Can you try toggling CAN DIN pin externally and check if system wakes up?

I transferred messages from CAN bus via transceiver and the CAN_RX pin on Jetson “see” the activity on bus;
But Jetson does not wake up.

[shgarg]

is your usecase to wake up jetson from sleep or wake using CAN?

[AliHaeri]

surely wake using CAN!!! The topic is CAN_WAKE, as well as the content of all previous posts…

Jetson wakes from sleep by plugging USB, HDMI, or other ways. That is OK.

I want to wake Jetson when a CAN message received.

[AliHaeri]

I’m still awaiting for a response.

[AliHaeri]

I’m still awaiting for a response.

It is not very hard to reproduce the problem.

On a Jetson TX2 developer kit flashed with Jetpack 4.5.1, one can enable CAN bus:

sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan

sudo ip link set can0 up type can bitrate 500000 

then put the system into deep sleep (SC7):

sudo systemctl suspend

then toggle the CAN_WAKE or CAN_RX pin between 0 and 3.3V, and see that the system does not wake up.

[AliHaeri]

I managed to solve the problem.

The CAN_WAKE pin is a GPIO. Its number is 300, based on PINMUX Spreadsheet.

(CAN_WAKE -> PAA.04 -> 256 + 5*8 + 4 = 256 + 44 = 300. "5" is the number corresponding to AA, according to tegra186-gpio.h file. 44 is important in device tree changes.)

I used the following procedure:

1- Do a fresh installation of JetPack, in my case, 4.5.1

2- Copy the tegra186-quill-p3310-1000-c03-00-base.dtb from the /Linux_for_Tegra/kernel/dtb directory on host machine, to make changes on it.

3- With the following command, use the device tree compiler to de-compile the dtb file to a dts file:

dtc -I dtb -O dts -o DeviceTreeDTS.dts tegra186-quill-p3310-1000-c03-00-base.dtb

4- Apply the following patch to the gpio-key section of the device tree file DeviceTreeDTS.dts:

	gpio-keys {
		compatible = "gpio-keys";
		gpio-keys,name = "gpio-keys";
		status = "okay";

		sw_wake {
			label = "sw-wake";
			interrupt-parent = <0x3a>;
			interrupts = <0x0 0x13 0x4>;
			linux,code = <0x74>;
			wakeup-source;
		};

		power {
			label = "Power";
			gpios = <0x28 0x38 0x1>;
			linux,code = <0x74>;
			gpio-key,wakeup;
		};

		volume_up {
			label = "Volume Up";
			gpios = <0x28 0x39 0x1>;
			linux,code = <0x73>;
		};

		volume_down {
			label = "Volume Down";
			gpios = <0x28 0x3a 0x1>;
			linux,code = <0x72>;
		};

		can_wake {
			label = "CAN WAKE";
			gpios = <0x28 0x2c 0x1>;
			linux,code = <0x8f>;
			gpio-key,wakeup;
		};

	};

The names can_wake and “CAN WAKE” has nothing to do with the actual device tree. Only arbitrary names. 0x2c is the hex value of 44, and 0x8f (143) is the linux code for KEY_WAKEUP.

5- Regenerate the dtb file:

dtc -I dts -O dtb -o tegra186-quill-p3310-1000-c03-00-base.dtb DeviceTreeDTS.dts

6- Re-flash the dtb file only, using the following command:

sudo ./flash.sh -k kernel-dtb jetson-tx2 mmcblk0p1

7- To test the functionality of wake pin, put the system into sleep:

sudo systemctl suspend

and then short the CAN_WAKE pin (Pin #1 of J26 on DevKit) to ground to resume the system.

Hope this will be useful.