Debug methods - IMX8QXP

[jnj]

Hi All,

I am currently working on IMX8QXP-MEK, and I have some queries regarding the debugging methods. I am a newbie to this platform. From the NXP documents, I came to know that there are mainly two methods to debug i.MX8. One is UART, and the second one is JTAG.

When the EVK is connected to the PC via USB, there are 4 UART ports visible: /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2, and /dev/ttyUSB3. Cortex A35 prints [Linux] can be seen over /dev/ttyUSB0, and M4 Cortex prints can be seen over /dev/ttyUSB2.

I am a little bit confused about which UART (among FTDIA, FTD_IB, FTDIC, FTDID ) is connected to Cortex A35 and Cortex M4 debugging.UART Connection diagram  of EVK is shown below.an JTAG be used for debugging both M4 and A35? Or can M4 only be debugged using JTAG? Kindly help me to resolve my doubts.

   Thanks in advance !

[jnj]

Hi @Chavira , 

Thank you for the response. Is there any Document to refer for debugging a35 cortex using debugging tool? Similarly among FTDIA, FTD_IB, FTDIC, FTDID in the schematics which Uart is connected to cortex a35 and cortex m4? 

[Chavira]

Hi @jnj!

For iMX8QXP the M and A Core have their peripherals.

In the schematic, you can see the connections between the FTDI and the iMX.

Check the Reference Manual in chapter 9 "Pin Assignment" and you can see the Peripherals for the M core and the A core.

The A core is debugged for the UART0 (Connected to FDTIA) and the M core is debugged on M40_UART0 (UART 0 for M core and connected to FTDIC), the UART3 is connected to FTDIB.

Sorry for the mistake!

Best Regards!
Chavira

[jnj]

Hi @Chavira ,

Thank you so much for the confirmation. I attempted to debug the Cortex-M4 using an MCUXpresso SDK demo, specifically the 'hello world' application. I connected the Segger J-Link and utilized the JLinkGDBserver and client. Successfully, I could observe the 'hello world' prints over /dev/ttyUSB2. However, the binary for the Cortex-M4 is not being updated. After rebooting, I am encountering the following prints over /dev/ttyUSB2.I have followed  mcuxpresso sdk guide.

 Is it possible to update the M4 demo bin in emmc using the Jlink? Is there any Document to refer for debugging a35 cortex using debugging tool?

[Chavira]

Hi!
Thank you for contacting NXP Support!

You have to flash your binary on the fat partition of the MMC.

Please check our "getting started" of the board to see the instructions for that.

You can use the uuu tool to update the fat partition of the board too.

You can flash only the m4.bin using the command below:

under u-boot use the command "fastboot 0", and connect the OTG port to the host.

uuu -b fat_write <m4.bin> mmc <device>:<particion> <name_on_board.bin>

https://www.nxp.com/document/guide/getting-started-with-the-mcimx8qxp-cpu:GS-MCIMX8QXP-CPU?section=m...

Best Regards!

Chavira

[jnj]

Hi @Chavira ,

Thank you for the response. Could you please elaborate this method of flashing only the hello_world.bin: 

uuu -b fat_write <m4.bin> mmc <device>:<particion> <name_on_board.bin>

In which document  can we find this ?

[Chavira]

Hi @jnj!

You can refer to the uuu documentation.

https://github.com/nxp-imx/mfgtools/releases/tag/uuu_1.5.125

[jnj]

Hi @Chavira ,

I have used the above mentioned uuu command over USB  to flash the hello_world.bin to emmc .I could flash the hello_world.bin to emmc vfat partition using the below command.

./uuu -b fat_write hello_world.bin mmc 0:1 hello_wrold.bin

After flashing I can see the hello_world.bin inside the mount point of mmcblk0p1 ie : /run/media/boot-mmcblk0p1

But while loading I am getting the below error

[Chavira]

Hi @jnj !

Try to corroborate if the image was flashed correctly using the command "fatls mmc 0:1", that command shoul list all the files saved in fat partition.

After that you have to use the commands

=>fatload mmc 1:1 0x88000000 hello_world.bin
=>dcache flush
=>bootaux 0x88000000


Best Regards!
Chavira

[jnj]

Hi @Chavira ,

I have checked the list of files in fat partition using the above mentioned command .The hello_world.bin file is showing in the list.But it throws an error when the hello_world.bin is tried to load as shown below

[Chavira]

Hi @jnj!

can you try again?

I don´t get errors.

Try with this binary

Best Regards!

Chavira

[jnj]

Hi @Chavira ,

Still I am facing the issue.As I discussed erlier ,already M4 core in my device is up and working .I am getting the following prints over /dev/ttyUSB2

 Could it be that I am unable to update the hello_world.bin because M4 is already up and running?And also I tried to see the debug prints of scu over /dev/ttyUSB1 and /dev/ttyUSB3 by turning on the switch SW4 in the imxqxp mek.But I couldn't see any uart prints .Do I need to enable anything from the scu fw.If yes could you please help me to get the scu fw link?

[jnj]

Hi @Chavira ,

Kindly help me

[Chavira]

Hi @jnj!

Can you try to re-flash the board?

I am using the image 6.1.55 without errors.

You can download the image by following the link:

https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for...

[jnj]

Hi @Chavira ,

I am working on version L5.15.71 .I will check with the 6.1.55 version also.Could you please update on this query :

"And also I tried to see the debug prints of scu over /dev/ttyUSB1 and /dev/ttyUSB3 by turning on the switch SW4 in the imxqxp mek.But I couldn't see any uart prints .Do I need to enable anything from the scu fw.If yes could you please help to guide me to update the change and kindly help me to get the scu fw link?I am little bit confused about the version"

[Chavira]

Hi @jnj!

To use the UART3 to usb port we have to change the device tree for that purpose.

The board uses the UART 3 underpins "FLEXCAN2_TX" and "FLEXCAN2_RX", and the balls connected to the USB port are "SCU_GPIO0_00 " and "SCU_GPIO0_01".

To use the uart3 under those pins we have to redefine the pinctrl of the uart3 of the device tree:

https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8x-mek.dtsi

After that, we can use the uart3 under Linux.

You can check how to compile the device tree on the next link:

 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-Devshell-to-compile-device-tr...

Best Regards!

Chavira

[jnj]

Hi @Chavira ,

I am little bit confused again. I want to debug SCU. In mek for the debugging scu_gpio0_IO00 and scu_gpio0_IO01 are connected to the USB converter FTD. When I checked the pinmux in the config tool these pins can be configured as SCU_UART0_TX and SCU_UART0_RX.And already a switch 4 is connected to use SCU debugging in the C0 mek.I want to utilise these pins and not UART3 for SCU under Linux

IF I am wrong, kindly correct me.

[jnj]

Hi @Chavira ,

Could you kindly update on how can we make use of the scu_gpio pins put in the MEK board to debug system controller unit?

[Chavira]

Hi @jnj !

Please check this guide.

[jnj]

Hi @Chavira ,

I will check this document. Regarding the M4 binary update, I downloaded the L5.15.71_2.2.1 pre-built binaries and flashed them using the following command:

./uuu 5.15.71_2.2.1.zip

After that, I attempted to update the M4 binary [hello_world.bin] by following the specified steps. While loading the binary using "fatload", I could see the print over /dev/ttyUSB2. However, my intention is to run the binary on every reboot of the device.

Previously, I flashed the Yocto image using the command:
./uuu -b emmc_all imx-boot-imx8qxpc0mek-sd.bin-flash_linux_m4 imx-image-full-imx8qxpc0mek-20240213094507.rootfs.wic.zst

If we flash using the above command, a sample code [power_mode_switch.bin] will be running on the M4 core.Since this bin is running,I was not able to fatload the hello_world.bin.

To make hello_world.bin runnable on every reboot I created flash.bin using the mkimage tool[make SOC=iMX8QX REV=c0 flash_linux_m4] and created flash.bin is flashed using ./uuu -b emmc imx-boot-imx8qxpc0mek-sd.bin-flash_linux_m4  flash.bin and it is was updated and on every reboot this binary is running on m4 cortex.

Previously, I attempted to flash it using the command:

./uuu flash.bin.

However, it was not running on the M4 core. I am a little confused about the interpretation of the binary name. Why did ./uuu flash.bin not update the binary, and why did the following command update the binary:

:/uuu -b emmc imx-boot-imx8qxpc0mek-sd.bin-flash_linux_m4  flash.bin ?

[Chavira]

Hi @jnj!

The uuu tool only flashes the first binary, in this case the first binary is "imx-boot-imx8qxpc0mek-sd.bin-flash_linux_m4", probably you don't include the M4 binary when you create the flash.bin

In this case I recommend using a flash.bin without an m4 binary, in this way you can upload a new m4 binary to test your application or use the debugger without problems.

To include the m4 image on the flash.bin image you should put the m4 binary with the name "m4_image.bin" to imx-mkimage/iMX8QX/.
Once all the needed binaries are inside of the folder iMX8QX you have to compile using the command "make SOC=iMX8QX flash_linux_m4" to create the correct flash.bin with the updated m4 image.