iMX8XD M4 project using VSCode / Keil

Hi,
I’m trying to setup my M4 project from the examples provided by NXP using the SDK (SDK_2_9_0_MIMX8UX5xxxFZ), however I have been not successful by debugging the examples provided by multicore.

The goal is to get a working environment using either KEIL or VSCode to debug M4 project.

VSCode approach:

(rpmsg_lite_pingpong_rtos)

This guide has been followed Developing M4 Applications Using Visual Studio Code as a first approach and everything is successfully installed and adjusted as well as in VSCode the cortex-debug.JLinkGDBServerPath and cortex-debug.gdbPath settings has been provided manually to inform VSCode where is my eabi-gdb and JLINKGDBSERVERCL exe are.

In the SDK provided by NXP you can see that the CMake files are adjusted only for MIMX8QX6, but in our case we are willing to work with the other device MIMX8UX5.

Using VSCode build tasks and adjusting all the CMake files to perform the same as the other device, had successfully provided me a compiled .bin and .elf files using Windows MinGW environment after adding the bin files from the suggested toolchain here (Linaro ARM Embedded/bare-metal toolchain, e.g. 4.8-2014-q3-update or 4.9-2015-q3-update).

Nevertheless, I had also adjusted my launch.json file in VSCode for accessing J-LINK API to use the debug node with providing device “MIMX8UX5_M4”.

CMakeLists.txt had also been adjusted to perform the same execution process that is applied on MIMX8QX6 to our device MIMX8UX5.

flages.cmake had also been adjusted to provide the proper variables needed in our approach regarding

  • CMAKE_ASM_FLAGS_DEBUG
  • CMAKE_C_FLAGS_DEBUG by adjusting the CPU to DCPU_MIMX8UX5AVLFZ (I’m sceptical on this)
  • CMAKE_EXE_LINKER_FLAGS_DEBUG by adjusting the linker from MIMX8QX6xxxxx_cm4_ram.ld to MIMX8UX5xxxxx_cm4_ram.ld (These files are provided under devices/gcc)

So, in principle, device_MIMX8UX5_startup_MIMX8UX5.cmake is responsible for using the startup file. And the Linker is approached by the variable that has been given in flages.cmake.

Trying to debug still fails in more than principle that I cannot understand why.
As in main_remote the main function is approachable, and it is recognized by the debugger, but still the app_task cannot be reached even after calling vTaskStartScheduler(). As the (void)PRINTF("\r\nRPMSG Ping-Pong FreeRTOS RTOS API Demo…\r\n"); cannot be seen and not breakable.

Maybe I can provide the project and my adjusts, so you can see where is my failures, maybe you can help me through.

Thanks!

Note: KEIL approach will be in another comment added. (rpmsg_lite_str_echo_rtos)


Colibri iMX8DX 1GB V1.0D
Iris Carrier Board V2.0
TorizonCore (2022-04-09 | 5.6.0+build.13)

You can discard the previous comment, it did work!!
I was missing out the adjustments regarding the pin_mux.h and pin_mux.c.

Nevertheless, there are several questions here that are bugging me:
1- Do I need the UART interface to communicate with an application between Linux (Containers) and M4 application? Using “imx_rpsmg_tty” or there are other ways to do that?
2- Do I even need this driver “imx_rpmsg_tty” to achieve the communication between both cores and receive the required data to user land? As I can see here there are several rpmsg drivers that are ready to be used. I have no idea what are they, can you please reference me to some documentations?
3- In Iris board should I use the same principle by adjusting the pin_mux of SC_P_SCU_GPIO0_00 for RX and SC_P_SCU_GPIO0_01 for TX, is it possible to receive the data using UART? Since I can’t see SODIMM 144 and 146 in the schematics by Iris board. Or how, suppose the data be transferred between the two cores by the Iris carrier?

1.1- As far as I know, the UART interface is not related to the communication between the Cortex-A (Linux) and Cortex-M. But it is useful for debugging purposes.
1.2- The imx_rpmsg_tty is a Linux Kernel Module (driver) that creates a (handy) TTY abstraction for the communication between the Cortexes. You can write your own driver to use RPMsg and establish communication between Cortex-A and Cortex-M.

2.1- If you are going to use the ttyRPMSG, then yes. But you can develop another driver that makes RPMsg available to userspace.
2.2- You can read MCUXpresso documentation about multicore examples. The imx_rpmsg_tty is the one that creates the TTY. The imx_rpmsg_pingpong is a simpler one that simply exchanges messages between both cores using RPMsg.

3.1- On Colibri iMX8X, SODIMM 144 and 146 must be used as UART RX/TX for M4. But, seems like those pins are not routed nor used on Iris V2.0. Maybe it is possible to change the default debug UART of M4 to some of the UARTs that are exposed on Iris. I am just not sure about that, as I have never done it. You would need to release the UART from Linux (from its device tree), and assign/configure it to/on M4.
3.2- As said before, the UART isn’t related to communication between both cores.

Seems like there was confusion between the RPMsg’s “UART” (which actually is an abstraction) and the “real” UART interfaces. I hope I could solve this confusion. Let me know :slight_smile:

Best regards,

4 Likes

Seems like there was confusion between the RPMsg’s “UART” (which actually is an abstraction) and the “real” UART interfaces. I hope I could solve this confusion.

Yeah, that’s right :smile:

If you are going to use the ttyRPMSG , then yes. But you can develop another driver that makes RPMsg available to userspace.

I think this is the best way to achieve our purpose.

On Colibri iMX8X, SODIMM 144 and 146 must be used as UART RX/TX for M4. But, seems like those pins are not routed nor used on Iris V2.0. Maybe it is possible to change the default debug UART of M4 to some of the UARTs that are exposed on Iris. I am just not sure about that, as I have never done it. You would need to release the UART from Linux (from its device tree), and assign/configure it to/on M4.

By developing our own driver, this won’t be relevant any more.

Thanks a lot!

Hi @pkg_su !

You are welcome :slight_smile:

If your question is solved, please mark the related message as a solution :wink:

Best regards,