AM623: DeepSleep wake using MCAN

Michael Shklyarman

Part Number: AM623
Other Parts Discussed in Thread: AM625

Champs,

Customer would like to be able to wake up from DeepSleep state when there is activity on Main Domain MCAN Rx pin. According to my reading of the TRM this should be feasible as MCAN Rx is not listed among pins that can not be used for wakeup, so it looks like if one enables PADCONFx.wkup_en for the main domain MCAN Rx pin it will wake up the device form DeepSleep. Questions:

1. Is this correct understanding?

2. it does not seem to be currently supported in the SDK - is there a plan to support such wakeup in foreseeable future?

3. if customer were to implement such wake up by themselves - is this feasible?

4. if it is feasible - what are the steps that need to be taken to achieve this?

thank you

Michael

over 2 years ago

0 Aparna Patra over 2 years ago

TI__Genius 12980 points

Hi Michael,

I have taken your inputs and working to get the answers. Please allow some time to revert back.

Regards,
Aparna

0 Tom Foy over 2 years ago in reply to Aparna Patra

Prodigy 121 points

Hello Aparna - I've been playing with different device tree configurations for this (referring to the SDK instructions and the example overlay), and regrettably not been able to make any progress so far.

I'm very much looking forward to hearing any progress from you on this. Namely, is it possible to configure a "Main domain" pin as a wakeup source on the AM62?.

For reference, our CAN transceiver is connected to the main AM62 at MCAN0_RX / MCAN0_TX (Ball E15 - not connected to the MCU). Should this be usable as a wakeup source?

Anyway, hoping we'll have some good news forthcoming!

Thanks,
Tom

0 Anshu Madwesh over 2 years ago in reply to Tom Foy

TI__Mastermind 22585 points

Hi Tom,

Thank you for your patience.

Can you clarify which SDK version you are using?

Currently, there is no documentation for using Main Domain MCAN as a wakeup source for Deep Sleep. In theory, it should be possible.

Important question before proceeding: Do you plan to use the MCAN wakeup source enabled at run time? There are two options:

1. If you do want it at run time (MCAN wakeup is enabled right before Deep Sleep), this is not currently possible since the pin control driver doesn't support MCAN. Its unknown if the pin control driver will be updated to support MCAN in the future

2. If it does not matter (MCAN wakeup will always be enabled), then this option is possible, but its behavior is not validated. So please understand that there might be some trial and error in this process.

The rest of this post is assuming option 2 is okay:

Review the datasheet to ensure that there are no conflicting signals on E15. Conflicting Mux Modes will create issues later.

Generally speaking, as long as there is a PADCONFIG Register for a specific pin, it can be used as a wakeup source. For Main Domain MCAN, PADCONFIG119 (MCAN0_RX) is required register. You can find this in the TRM Rev B: Table 14-6173. Pad Configuration PADCONFIG Registers.

Bit 29 of the register needs to be set to 1 to enable wakeup on the signal. This will tell the DM Firmware on the R5F core to watch out for a wakeup interrupt when the device is in deep sleep. Access the register via U-Boot prompt or Linux Userspace.

There are also required Device Tree changes, but I am still trying to understand this myself. Please allow some time for this and I will updated this thread accordingly.

I understand this is a lot of information, so feel free to ask any clarifying questions. Hope this helps.

Best Regards,

Anshu

0 Tom Foy over 2 years ago in reply to Anshu Madwesh

Prodigy 121 points

Hello Anshu - thanks for your considered response, it's appreciated.

Before I answer your questions, I should say that we are currently investigating a different approach to this problem in our product design, that will not involve using CAN activity as a wakeup source.

Now, to answer your questions - although there's no need for a response (unless we return to this design) ... I'm just answering to tie up the loose end.

Yes, we were planning to use this at run time (basically, we enter deep sleep, then trigger the wakeup event on activity on the MCAN0_Rx pin). I've been playing with different options with the device tree and I think I've reached the same conclusion as you (that it's not validated).

I'm encouraged by your equal confusion with the device tree settings here as I was much puzzled by it for a couple of days also!

Anyway, for now we're proceeding with a different design mechanism - but thanks for your input on this so far.

Tom

0 Anshu Madwesh over 2 years ago in reply to Tom Foy

TI__Mastermind 22585 points

Hi Tom,

Thanks for the update. This thread will be closed until you have a follow up question.

Best Regards,

Anshu

0 Anshu Madwesh over 2 years ago in reply to Anshu Madwesh

TI__Mastermind 22585 points

Hi Tom,

I understand that you are moving forward with a different design, but I wanted to close the loop here.

Here are the device tree changes I made to k3-am62x-sk-lpm-wkup-sources.dtso which is the LPM device tree overlay:
To future readers, the WKUP_EN is only needed for Partial IO Mode since the PADCONFIG will take care of making the Pin ready for wakeup.

&main_pmx0 {
	mcan0_tx_pins_default: mcan0-tx-pins-default {
		pinctrl-single,pins = <
			AM62AX_IOPAD(0x01d8, PIN_OUTPUT, 0) /* (B17) MCAN0_TX */
		>;
	};

	mcan0_rx_pins_default: mcan0-rx-pins-default {
		pinctrl-single,pins = <
			AM62AX_IOPAD(0x01dc, PIN_INPUT, 0) /* (C18) MCAN0_RX */
		>;
	};

	mcan0_rx_pins_wakeup: mcan0-rx-pins-wakeup {
		pinctrl-single,pins = <
			AM62AX_IOPAD(0x01dc, PIN_INPUT | WKUP_EN, 0) /* (C18) MCAN0_RX */
		>;
	};
};

&main_mcan0 {
	pinctrl-names = "default", "wakeup";
	pinctrl-0 = <&mcan0_tx_pins_default>, <&mcan0_rx_pins_default>;
	pinctrl-1 = <&mcan0_tx_pins_default>, <&mcan0_rx_pins_wakeup>;
	status = "okay";
};

Then in the Linux terminal, adjust the PADCONFIG119 (MCAN0_RX) register with an updated Bit 29:

root@am62axx-evm:~# devmem2 0xF41DC
/dev/mem opened.
Memory mapped at address 0xffffbd59a000.
Read at address  0x000F41DC (0xffffbd59a1dc): 0x00050000
root@am62axx-evm::~# devmem2 0xF41DC w 0x20050000
/dev/mem opened.
Memory mapped at address 0xffffbe172000.
Read at address  0x000F41DC (0xffffbe1721dc): 0x00050000
Write at address 0x000F41DC (0xffffbe1721dc): 0x20050000, readback 0x20050000

Took the original hex value in the register and then change Bit 29 to 1. Then wrote the same register with the new value.

Finally, Suspend to RAM Logs:

root@am62axx-evm:~# echo mem > /sys/power/state 
[   44.621058] PM: suspend entry (deep)
[   44.628741] Filesystems sync: 0.003 seconds
[   44.652484] remoteproc remoteproc1: stopped remote processor 79000000.r5f
[   44.659738] Freezing user space processes
[   44.665411] Freezing user space processes completed (elapsed 0.001 seconds)
[   44.672406] OOM killer disabled.
[   44.675633] Freezing remaining freezable tasks
[   44.681400] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[   44.688814] printk: Suspending console(s) (use no_console_suspend to debug)
[   44.710138] omap8250 2800000.serial: PM domain pd:146 will not be powered off
[   44.716666] Disabling non-boot CPUs ...
[   44.718602] psci: CPU1 killed (polled 0 ms)
[   44.721161] psci: CPU2 killed (polled 0 ms)
[   44.722981] psci: CPU3 killed (polled 4 ms)
[   44.723830] Enabling non-boot CPUs ...
[   44.724142] Detected VIPT I-cache on CPU1
[   44.724209] GICv3: CPU1: found redistributor 1 region 0:0x00000000018a0000
[   44.724261] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[   44.725024] CPU1 is up
[   44.725247] Detected VIPT I-cache on CPU2
[   44.725286] GICv3: CPU2: found redistributor 2 region 0:0x00000000018c0000
[   44.725322] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[   44.725886] CPU2 is up
[   44.726115] Detected VIPT I-cache on CPU3
[   44.726156] GICv3: CPU3: found redistributor 3 region 0:0x00000000018e0000
[   44.726195] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[   44.726847] CPU3 is up
[   44.727392] ti-sci 44043000.system-controller: ti_sci_resume: wakeup source: 0x80
[   44.735966] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
[   44.749804] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)
[   44.749828] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
[   44.998569] OOM killer enabled.
[   45.001712] Restarting tasks ... done.
[   45.007260] random: crng reseeded on system resumption
[   45.012569] remoteproc remoteproc1: powering up 79000000.r5f
[   45.018294] remoteproc remoteproc1: Booting fw image am62a-mcu-r5f0_0-fw, size 52148
[   45.027165] rproc-virtio rproc-virtio.6.auto: assigned reserved memory node r5f-dma-memory@9b800000
[   45.037115] virtio_rpmsg_bus virtio1: rpmsg host is online
[   45.042741] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
[   45.043425] rproc-virtio rproc-virtio.6.auto: registered virtio1 (type 7)
[   45.060945] remoteproc remoteproc1: remote processor 79000000.r5f is now up
[   45.066401] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
[   45.075525] PM: suspend exit
root@am62axx-evm:~# ^C

Notice that the wakeup source is 0x80 for MAIN_IO not 0x82 for CAN_IO. Here is the TISCI documentation for wakeup sources: https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html

Please note that I validated this on AM62A, but the process is identical for AM62x.

Thanks,

Anshu

0 Tom Foy over 2 years ago in reply to Anshu Madwesh

Prodigy 121 points

Thanks Anshu - appreciated!

0 Tom Foy over 2 years ago in reply to Tom Foy

Prodigy 121 points

Hey Anshu - I managed to get this working on my AM625 today and can confirm that I was able to Wake-from-CAN activity!

Thanks again!

Tom

0 Anshu Madwesh over 2 years ago in reply to Tom Foy

TI__Mastermind 22585 points

Hi Tom,

Thanks for the update and glad that its working. This thread will be closed for now.

Best Regards,

Anshu

Processors

Processors forum

AM623: DeepSleep wake using MCAN