hello, I am using Ixora board v1.3 and apalis IMX8QM.
I’m trying to run hello world using cortex-M. But I don’t get any output when running the program even though the program has printf in the while loop. I have tried to check with serial from UART1 which is located in picocom. But the serial only displays u-boot and boot log. Even though I need the printout for debugging.
I have followed the following requirements How to Run a Hello World on the Cortex-M. should I use evaluation board to access cortex-m serial? or should I add custom device tree overlay for cortex-m40 and cortex-m41?
I have tried this solution controlling-the-peripheral-in-imx8-with-m4-core and it does work for debugging serial core 1 on the ixora board. my question is whether for core 0 can’t be treated the same way? i mean core 0 is also debugged with the same pins as core 1 by equating the pin names in pin_mux.h
can the process not be that simple or how? or is there another way so that I can debug serial core 0 on the ixora board?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Azka,
Based on the context provided, it seems that you are facing issues with obtaining output from your Cortex-M application on the Ixora board v1.3 with the Apalis IMX8QM. Here are some recommendations:
Device Tree Overlays: It is advisable to add a custom device tree overlay for Cortex-M40 and Cortex-M41 to ensure that the correct UART settings are applied. This can help in routing the serial output correctly for debugging purposes.
Evaluation Board: While using an evaluation board specifically designed for Cortex-M may simplify the debugging process, it is not strictly necessary if you can configure the Ixora board correctly. However, evaluation boards often come with pre-configured settings that facilitate easier access to serial outputs.
Debugging Core 0 vs. Core 1: Debugging core 0 may not be as straightforward as core 1 due to potential differences in configuration or pin assignments. While you can equate pin names in pin_mux.h, additional configurations may be required to ensure that core 0 is properly set up for serial output.
Unique Requirements: Each core may have unique requirements for debugging, which should be taken into account. It is essential to verify that all necessary configurations are applied for both cores, including checking the device tree settings and ensuring that the correct UART is being used for output.
If issues persist, exploring alternative debugging methods or tools may provide further insights into the problem. If you have any further questions or need additional assistance, feel free to ask!
Best regards,
Azka
Please, also check if these links can help you solve your problem:
You are asking a lot of questions here, so I’m going to go 1 by 1.
Can you explain how are you accessing the UART1? Which of the Ixora pins exactly are you accessing?
We recommend using the Apalis Evaluation Board for cortex-M development because the Ixora carrier board don’t exposes all of the SoC interfaces. If you have a development board, then yes, you should use it.
Yes you need to apply a custom device tree overlay, you can find the source at the “Apply the Device Tree Overlay” section of this article.
Happy to know that you got it working.
Well…This is more of an hardware issue.
The signals from the cortex-M are not routed to the same place.
So… can you elaborate on what is your project goals?
You want to use both the cortex-M cores?
Do you plan to use the Ixora carrier board in the final product?
I use UART1 on the x22 socket to display u-boot and boot results using picocom. But I was confused about the use of UART2/3 on the x21 socket
My project goal is to use both cortex m for communication access needs and realtime processing as centralized control. And of course I will use this ixora carrier board as my final product.
Therefore, how can I use both of the two cortex m especially the debug part with different UARTs I think is also not a problem. from your explanation I realized that the interface of m0 and m1 should be different.
I see… so you are using the DB9 connector right? You can always refer to the ixora schematics to have a better idea, but basically on the Ixora carrier board, the UART signals are converted to R232 format before it is exposed on the carrier board pins. What is the confusion exactly?
Well… we usually recommend that you develop your product using the evaluation board and later change it to either a custom carrier board or one of our production carrier boards. I think that is the easiest solution.
My confusion is what are the possible applications in utilizing this UART 2/3. can’t I change the code in pin_mux.h on core 0 and change it to a pin name that refers to UART 2/3 and then connect USB to TTL to it? or is that not how the MCUexpresso SDK works?
/* M40_I2C0_SCL (number AM44), FTDI_M40_UART0_RX */
/* Routed pin properties */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_PERIPHERAL M40__UART0 /*!< Peripheral name */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_SIGNAL uart_rx /*!< Signal name */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_NAME M40_I2C0_SCL /*!< Routed pin name */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID SC_P_M40_I2C0_SCL /*!< Pin function id */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_LABEL "FTDI_M40_UART0_RX" /*!< Label */
#define BOARD_INITPINS_FTDI_M40_UART0_RX_NAME "FTDI_M40_UART0_RX" /*!< Identifier */
/* M40_I2C0_SDA (number AU51), FTDI_M40_UART0_TX */
/* Routed pin properties */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_PERIPHERAL M40__UART0 /*!< Peripheral name */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_SIGNAL uart_tx /*!< Signal name */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_NAME M40_I2C0_SDA /*!< Routed pin name */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID SC_P_M40_I2C0_SDA /*!< Pin function id */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_LABEL "FTDI_M40_UART0_TX" /*!< Label */
#define BOARD_INITPINS_FTDI_M40_UART0_TX_NAME "FTDI_M40_UART0_TX" /*!< Identifier */
Sorry, but I think you are mixing up a lot of things here.
USB to TTL and R232
First, you can’t communicate a R232 interface using a USB-TTL adapter because the R232 operates at a voltage way higher than the USB this adapter and also they don’t use the same logic for communication. To access the pins in the R232 pin header you need a R232 converter.
Pinmuxing
That’s not exactly how pinmuxing works.
First, open the Apalis iMX8 SoM Datasheet and go to the SoC Functions List table.
Each X1 Pin (the golden pads in the SoM) have a predefined set of fuctions that it can operate.
The pinmuxing is used to select which function is enabled for this pad.
And this is what you are setting in the pin_mux.h file.
Carrier board interface
Last, you have the Ixora carrier board, that exposes the SoM interfaces.
Here, the Apalis iMX8 SoM pads are routed to external interfaces in the Ixora carrier board.
This routing is a physical electrical connection and, in general, can’t be routed to another pin.
The Ixora UART2/3 on the x21 socket is a physical interface, you can’t change which Apalis pads are routed here. This is what the schematics are showing.
Here’s a breakdown of the hello_world example.
/* UART0_RTS_B (number AU45), BB_UART2_RX/J20A[28] */
/* Routed pin properties */
#define BOARD_INITPINS_BB_UART2_RX_PERIPHERAL DMA__UART2 /*!< Peripheral name */
#define BOARD_INITPINS_BB_UART2_RX_SIGNAL uart_rx /*!< Signal name */
#define BOARD_INITPINS_BB_UART2_RX_PIN_NAME UART0_RTS_B /*!< Routed pin name */
#define BOARD_INITPINS_BB_UART2_RX_PIN_FUNCTION_ID SC_P_UART0_RTS_B /*!< Pin function id */
#define BOARD_INITPINS_BB_UART2_RX_LABEL "BB_UART2_RX/J20A[28]" /*!< Label */
#define BOARD_INITPINS_BB_UART2_RX_NAME "BB_UART2_RX" /*!< Identifier */
in the pin_mux.h file, you are taking the Apalis iMX8 pin named UART0_RTS_B and setting it to operate as a DMA__UART2.RX function, to enable the UART communication.
Here, those signals are exposed in the Extension Header (X27) pin 35.
You can see that this pin is called PWM3 in the Ixora, but it configured to act as a UART.RX.
well thanks for the answer. now I understand enough to trace the usage on SoM and board.
From your previous explanation that it cannot use UART 2/3 on pinmux.h, is it not possible to change the SoC function used on pinmux.h to another pin that can function as a UART? that way I can use serial debug there. Maybe if the MCUExpressoSDK doesn’t allow doing that I can’t do anything because I just want to try an alternative way so that I can monitor all m0 and m1 with serial debug.
For UART 2/3 it seems that you are right that I misunderstood the way to access it which must use the RS232 interface.
