AM623: AM623

Robert Grizilo

Part Number: AM623

Tool/software:

Greetings,

I'm still far away from the start of the project, but now it's the best time to have a good picture of how to approach the development.

As far as I have read in the AM62x academy, there is no way to have some sensors connected via, e.g. i2c or serial that can be managed by both core types (A and R) at the same time, I mean not really at the same time but sort of runtime switchable ownership (Device Manager).

For example let's make a scenario:

Linux boots, initializes all devices (DTB) and drivers, the remote core enabled, prepares and runs the firmware (control application) for the R (MCU) core, and runs the main application on Linux (A core). Let's call the main application on the A core and the control application (firmware) on the R (MCU) remote core. The main core has drivers for all i2c sensors, while the CANFD is connected directly to the MCU core and linux has no idea about it and both applications communicate via IPC (so the main application can read and write to CANFD through IPC and control application).

The control application (firmware) will be in C++/FreeRTOS and it will read/write to CANFD and exchanges information via IPC with the main application that do the data processesing.

In addition to CANFD running all the time, the control application (firmware) also has an inactive part of the code that should only be active when the processor needs to enter low power mode. In this mode (when the main A core shutted down), the MCU should take over the reading of the sensors connected to i2c and based on certain readings it should wake up the main A core, then release the i2c sensor and return to the main CANFD/IPC mode only, so the linux could continue running as nothing happens.

According to the AM62x academy Device Manager (the boss) is either A core or MCU (R) core, is it the only correct way to remove all sensors from the A core (remove from DTB) so that linux does not control any sensor and do all the control within the firmware (control application) and then through IPC exchange all information with the main A core, or is there another way to free up the sensors from the driver within linux before shutting down the A core, switch owership to the R (MCU) core and then, when waking up the main core, return the ownership back to the A core so the drivers can continue normal functioning?

Seems complicated, but then again, I want to build a device that will have all the bang and whistles while running on full power with linux drivers and all those comodities, and when the device stays on battery in power saving mode, control should be given to simple MCU that will rarely control some sensors (turn off power hungry main A core) and if some specific values are on sensors or data is received trough CANFD, the device go back to full bang and whistles.

Best regards,
Robert

21 days ago

0 Nick Saulnier 20 days ago

TI__Guru* 76425 points

Hello Robert,

For a general purpose usecase, that is correct. TI only supports a single software instance controlling the peripheral, unless the peripheral was specifically designed for multiple software instances to interact with it at once (e.g., the DDR interface).

In general, Linux drivers are not written to be initialized and de-initialized during normal runtime. So we would not support the usecase of Linux and the DM R5F core both sending and receiving messages from the CAN, or passing the CAN back and forth during runtime.

With that said, there MIGHT be a way to do what you are trying to do. We have NOT tested what I am about to say, so it may or may actually be possible. And I cannot promise that we would be able to support questions if you decided to try to get it to work. It might be easier to simply set up a "normal" wakeup source, as described at https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_02_01_09/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Power_Management/pm_wakeup_sources.html

Hypothetical usecase: MCU M4F core

First off, the peripherals would need to be in the MCU domain, because otherwise they would not be clocked during low power mode. You would use MCU only low power mode https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_02_01_09/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Power_Management/pm_low_power_modes.html#mcu-only

IF #1

When Linux powered itself down, I would expect Linux to message the DM firmware running on the DM R5F to release all of Linux's peripherals (I am NOT SURE if this is actually how it works).

IF #2

IF that is how it works, then after the peripherals are released, it is possible that the MCU M4F could request ownership of the peripherals from the DM R5F. That's the second IF: I am not sure if the DM R5F can still receive requests for peripheral ownership after a low power mode transition has taken place. The DM R5F has to move its code from DDR into local memory before the low power mode transition, so it may or may not still be listening for those kinds of requests, I'm not sure.

If both of those things are possible, then the MCU domain peripheral could monitor the peripheral traffic. After receiving a certain input, it could release ownership of the peripheral, and THEN wake up the rest of the processor after that process had finished.

Regards,

Nick

0 Robert Grizilo 18 days ago in reply to Nick Saulnier

Prodigy 30 points

Thanks Nick for your expert reflection.

Looking at all the problems and limitations and the experimental nature of the desired approach, it seems to me that the smartest choice is to transfer most of the sensor IO to the MCU, which has to access most of the sensors at some point in time anyway. Since communication with sensors through the MCU does not go through already written linux drivers and that code must be written for the MCU anyway, I don't see any benefit in experimenting with switching the ownership of the device between these two types of cores.

I think that the focus should be on the IPC protocol that will transmit all the various forms of data types between the cores and the mentioned sensors and devices like CANFD, temp/humidity, accel/gyro, gps, etc. When the conditions are met, the MCU turn on the linux core, which continues to do advanced things (such as connecting to the internet via e.g. cellular network, wifi, etc.) and again through IPC asks for statuses that woke it up and do higher level of processing.

Source code for the linux drivers is available for the choosen sensors and devices, so using the original source code should help to write appropiate drivers for the MCU.
GPS could be more complex regarding all the modes of operation it support, but temp/humidity, accel/gyro, voltages etc. looks simpler and using FreeRTOS and threads it should be not so complicated.

It would be much simpler from the development point of view to have one core type, everything running in linux and when power constrained modes are needed that you could just slow down the core(s) to slugish speed (perhaps turn off devices not needed) and save the power.

Best regards,
Robert

0 Nick Saulnier 17 days ago in reply to Robert Grizilo

TI__Guru* 76425 points

Hello Robert,

That sounds like sound logic to me.

You've already found the AM62x multicore academy, but for future readers with any IPC questions, please refer to the IPC module of the multicore academy: https://dev.ti.com/tirex/explore/node?node=A__AW2nwtkfXMNMKfHQ-xFw9g__AM62-ACADEMY__uiYMDcq__LATEST

If you are designing your IPC solution and have any followup questions about that, feel free to create a new thread. It will come to me or one of my MCU+ side team members, and we'll be able to talk through design options with you.

Regards,

Nick

Processors

Processors forum

AM623: AM623