Colibri iMX8X Cortex M4 FreeRTOS


I’m testing the software examples from NXP (SDK_2.5.2_MIMX8QX6xxxFZ). My problem is, if I start the m4 core with diffrent code examples, nothing happens and the cortex A35 doesn’t boot anymore. Without the m4, it’s no problem to run a linux image on it.

Does anybody know why the software examples don’t work and what I have to change to run them correctly?

Every help is appreciated.

Thank you for your reply.
I’ve assigned the correct Uart pins and it works fine now.

Hi @developerTirol

Can you please provide me detailed instructions how to reproduce the problem.

I took a Colibri iMX8X with default Linux installation, ran the SDK’s HelloWorld example from U-Boot and booted Linux from U-Boot - All working fine.

The HelloWorld expectedly doesn’t give output, because the debug port is mapped to the wrong UART pins. Still Linux is booting fine with this configuration.

Regards, Andy

Hi @andy.tx , How can I correct the right UART mapping for M4 console output? Thanks!

Hi @benjamin.tx
Modifying the following definitions in pin_mux.h should do the trick:

/* ADC_IN2 (coord V32), FTDI_M40_UART0_RX */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_PERIPHERAL             M40__UART0   /*!< Device name: M40__UART0 */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_SIGNAL                    uart_rx   /*!< M40__UART0 signal: uart_rx */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_NAME             SCU_GPIO0_00   /*!< Pin name */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID SC_P_SCU_GPIO0_00   /*!< Pin function id */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_LABEL              "M40_UART0_RX"   /*!< Label */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_NAME               "M40_UART0_RX"   /*!< Identifier name */

/* ADC_IN3 (coord V30), FTDI_M40_UART0_TX */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_PERIPHERAL             M40__UART0   /*!< Device name: M40__UART0 */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_SIGNAL                    uart_tx   /*!< M40__UART0 signal: uart_tx */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_NAME             SCU_GPIO0_01   /*!< Pin name */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID SC_P_SCU_GPIO0_01   /*!< Pin function id */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_LABEL              "M40_UART0_TX"   /*!< Label */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_NAME               "M40_UART0_TX"   /*!< Identifier name */

Regards, Andy

Thanks very much!

Hello everyone ! I’m try to make exactly the same thing work, and still nothing. What I’ve done:

  1. modified pin_mux.h with your pin data
  2. compiled the demo hello_world project using GCC toolchain
  3. launched the elf file with the toolchain’s gdb
  4. connected gdb to SEGGER GDB server (device MIMX8QX6_M4)
  5. typed monitor reset, monitor halt, load, monitor go into gdb
Downloading 2560 bytes @ address 0x1FFE0000 - Verified OK
Downloading 16 bytes @ address 0x1FFE0A00 - Verified OK
Downloading 11648 bytes @ address 0x1FFE0A10 - Verified OK
Downloading 8 bytes @ address 0x1FFE3790 - Verified OK
Downloading 4 bytes @ address 0x1FFE3798 - Verified OK
Downloading 4 bytes @ address 0x1FFE379C - Verified OK
Downloading 104 bytes @ address 0x1FFE37A0 - Verified OK
Writing register (PC = 0x1ffe0ac4)
Received monitor command: go
Starting target CPU...
  1. Connected UART B in the Colibri evaluation board and nothing. I also tried output in pins 144/146

Any ideas ? Do I need to make a device tree file to activate pins 144/146 (UART_M4) ? It is mentionned nowhere in the documentation

Hi @luciolis , except the pin_mux.h file, you also need to modify the pin_mux.c .

void BOARD_InitPins(sc_ipc_t ipc)                          /*!< Function assigned for the core: Cortex-M4F[m4] */
  sc_err_t err = SC_ERR_NONE;

  err = sc_pad_set_all(ipc, BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID, 2U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF, 0x0 ,SC_PAD_WAKEUP_OFF);/* IOMUXD_ADC_IN2 register modification value */
  if (SC_ERR_NONE != err)
  err = sc_pad_set_all(ipc, BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID, 2U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF, 0x0 ,SC_PAD_WAKEUP_OFF);/* IOMUXD_ADC_IN3 register modification value */
  if (SC_ERR_NONE != err)

Hi ! Thanks ! Still nothing on the UARTB, any idea ?

The NXP tutorial talks of a “SEGGER patch”, that is unavailable online. Do you have any idea of what it is?

Hi @luciolis , to make this issue clear, could you test m4_0.bin (8.4 KB)
on your Colibri iMX8X setting? Boot it from U-boot instead of SEGGER JTAG. For example, load it via tftp, tftp ${loadaddr} m4_0.bin; dcache flush; bootaux ${loadaddr} 0.
It does print “hello world.” on UARTB at my side. However, I don’t have a SEGGER JTAG.

Hi @benjamin.tx ,
I also tested the demo (hello_world and igpio_led_output) which are available inside the SDK , it works for me as well. with the changes in pin_mux.c and pin_mux.h

I am currently trying to get the m4@imx8x (imx8dx) up and running.
I managed to get a simplyfied version of the gpi_led_output example to run (only LED blinking on LSIO.GPIO1.IO23 (corresponding to X1.21 on imx8x), but when I try to get the UART to run there is nothing.

I already changed pin_mux.c (both 1U-> 2U) and pin_mux.h (ADC_IN2/3 → SCU_GPIO0_00 including SC_P and corresponding label /name), but There is still no communication on the UART-B on my Colibri evaluation board.
Can someone help me?

Hi @cillex !

Welcome to Toradex Community! :tada:

As you can see, this thread is a bit old.

It would be better if you could create a new thread, so we can discuss specifically your issue.

But, anyway, I would like to point you to our documentation specifically for Colibri iMX8X’s Cortex M

You will be able to find it from this page: Real Time Documentation Overview | Toradex Developer Center

If you have further questions, please create a new thread :slight_smile:

Best regards,

1 Like

Hello @cillex ,
Were you able to solve your issue?

Best regards,

Yes, thank you for the quick response.

I didn’t use aUSB/TTL converter, it was never mentioned in previous documentations and no search prompt sent to me to documentation you provided.

The UAR works perfectly fine now.
Next will be a GPIO Interrupt handler, but this is something for another topic.

Best regards,

Hello @cillex ,
Thanks for the feedback.

Best regards