Carrier: Toradex Dahlia V1.1D
CPU: i.MX8MMDL rev1.0
OS: FreeRTOS
I want to use the UART2 port of X19 (Pin 14, 15) of Toradex Dahlia V1.1D for serial communication from Coretex-M4.
Is there a way?
I have done the following, but Tx data is not sent (check the PIN status)
Hi @katsu , please share the FreeRTOS code you are using.
Are you using your own original code or is it a Toradex sample? Does the UART TX work at all if you use any other UART?
Kind regards,
Alvaro.
UART4 is changed to UART3 in the sample code of [EVK-MIMX8MM-hello_world].
Changes have been made based on the following.
No signal appears in the Tx signal (X20:Pin13).
I checked with a logic analyzer.
Did you check this post? Apparently you don’t need to update U-Boot.
It seems you also need to activate the UART3.clk
Kindly confirm.
Alvaro.
Yes, we have already confirmed the post and are conducting an experiment.
As a result, no Tx signal is output from UART2 (X19:14/15).
while (0U == (base->USR2 & UART_USR2_TXDC_MASK))
It will loop forever.
My understanding is that UART2 on the Dahlia board is linked to UART3 on the VerdinSOC. I’m guessing that I need to allocate UART2 to Cortex-M4 resources using RDC.
Am I wrong?
Correct. Yes, Dahlia (Verdin family) UART2 (X19:14/15) is i.MX8MM UART3. X1_139 and X1_137.
I recommend using the X1 (SODIMM Edge Connector) pin number since this is used for SOM and Carrier Board.
Can you share your FreeRTOS code? Including pin_mux.c, board.c, and any other changes you have done to the original code.
As a result, no Tx signal is output from UART2 (X19:14/15).
while (0U == (base->USR2 & UART_USR2_TXDC_MASK))
Where is that in the code?
Thanks,
Alvaro.
Changes have been made to the following four files from [EVK-MIMX8MM-hello_world]-[hello_world].
Defines marked with “@@” are changed and added.
Permanent loop location
fsl_uart.c
status_t UART_WriteBlocking()…Line:710
I recommend using the X1 (SODIMM Edge Connector) pin number since this is used for SOM and Carrier Board.
What does it mean?
thank you
board.c (8.3 KB)
board.h (2.3 KB)
clock_config.c (5.2 KB)
pin_mux.c (3.4 KB)
fsl_uart.c (58.0 KB)
Thanks a lot @katsu . Let us check and we will get back to you.
@jorge.tx has been recently working with Cortex M so hopefully he can reproduce the issue and get back to you with the details within this week.
Kindly wait a little longer.
I recommend using the X1 (SODIMM Edge Connector) pin number since this is used for SOM and Carrier Board.
What does it mean?
From Verdin iMX8M Mini datasheet:
From Dahlia Carrier Board datasheet:
Is just that it is less confusing for everyone since Verdin and NXP UART naming is not the same for i.MX8M Mini.
Thanks a lot,
Alvaro.
Does that mean it’s better to express it as the Verdin pin (X1) number?
It was certainly confusing at first.
Is it correct to understand that there is no need to change U-BOOT in this case?
I’m currently implementing both approaches: Cortex-M4 code debugging and U-BOOT modification, so I’d like to narrow it down to one or the other.
We apologize for the inconvenience and thank you for your understanding during your busy schedule.
Does that mean it’s better to express it as the Verdin pin (X1) number?
Yes, since functions can be pinmux, it is best to just use the physical pin of X1. No confusion there.
Is it correct to understand that there is no need to change U-BOOT in this case?
I’m currently implementing both approaches: Cortex-M4 code debugging and U-BOOT modification, so I’d like to narrow it down to one or the other.
I think we can focus in the Cortex-M4 code. The original post mentions that only “FreeRTOS code modification is needed” and I just checked that the iMX8MM UART3 is not mentioned or used in U-boot. Only UART1 (X1_147 and X1_149) is used:
Kind regards,
Alvaro.
Write down the data after starting Linux.
torizon@verdin-imx8mm-14756527:~$ dmesg | grep tty
[ 0.000469] printk: console [tty0] enabled
[ 0.881306] 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 42, base_baud = 1500000) is a IMX
[ 0.881448] printk: console [ttymxc0] enabled
[ 0.881988] 30880000.serial: ttymxc2 at MMIO 0x30880000 (irq = 43, base_baud = 1500000) is a IMX
[ 0.882435] 30890000.serial: ttymxc1 at MMIO 0x30890000 (irq = 44, base_baud = 1500000) is a IMX
In this case, resources are likely to be allocated to Cortex-A.
Is it possible to access (ttymxc1, ttymxc2) resources from Cortex-M?
This is the data output result to tty
torizon@verdin-imx8mm-14756527:~$ ll /dev/verdin-uart*
lrwxrwxrwx 1 root root 7 Feb 6 02:11 /dev/verdin-uart1 → ttymxc1
lrwxrwxrwx 1 root root 7 Feb 6 02:11 /dev/verdin-uart2 → ttymxc2
lrwxrwxrwx 1 root root 7 Feb 6 02:11 /dev/verdin-uart3 → ttymxc0
torizon@verdin-imx8mm-14756527:~$ echo test > /dev/ttymxc0 → Data output to Linux terminal
test
torizon@verdin-imx8mm-14756527:~$ echo test > /dev/ttymxc1 → Data output to X1_129/131
torizon@verdin-imx8mm-14756527:~$ echo test > /dev/ttymxc2 → Data output to X1_137/139
This is the current situation. Please let me know if you try anything else.
Ah, maybe you are not launching M core from U-Boot?
Yes, Linux uses all UARTs but one should not launch Linux to run the M core (not without changing the device tree from Linux to disable the UART3 you will use with the M core). U-Boot pinmux and Linux pinmux are separated.
You should stop U-Boot autoboot and launch M core (M core is not launched automatically):
Don’t let Linux run to test M core.
Kind regards,
Alvaro.
What happens when I connect ICE (Computex: PALiCE4) to JTAG to debug Cortex-M code?
If a debugger is not connected, the above content (EXT4LOAD) has already been implemented and tested. It is still not displayed.
I’ll check it again.
The information for using a JTAG is here, did you check it?
But you don’t need a JTAG to load a binary and run the M core.
Just checking but did you run the commands to load the binary and then “run m4boot”?
I suggest you also check the example with UART4 (default option) (that uses X1_153 & X1_151) and see if you get the serial output. Then try to focus to make the change to UART3.
Kind regards
Alvaro.
Confirmation with UART4 has been completed.
We have implemented it up to the end of this page and have confirmed that debugging is displayed correctly on UART4 without a debugger connected.
UART4 cannot be used when connecting a debugger, so it is not connected. This means that you want to use UART2 (X1:129/131) or UART3 (X1:137/139) for communication with external devices.
Things have changed.
When I connected a USB serial to X137/139 without connecting a debugger (Computex PALMiCE4), I was able to output to the terminal using UART3.
UART2 could not output to X129/131.
However, when I connect a debugger,
while (0U == (base->USR2 & UART_USR2_TXDC_MASK))
It’s looping.
This may be a problem with the way Cortex-M4 code is executed from the debugger.
Thank you for responding to these questions.
Let’s check the debugger startup.
Thanks for the confirmation @katsu
I didn’t know the limitation of connecting the JTAG
@alvaro.tx
Thank you for reply,
We apologize for not providing enough information.
Although the operation has not been fully confirmed using a debugger, we have confirmed that it can be connected to external devices other than the M4 debug port.
thank you.
The reason why I can’t output to X1_129/X1_131 is still not resolved.
Is there anything I should check?
@jorge.tx will check and get back to you but ideally should be the changes already mentioned.
Jorge, please check.
Thanks,
Alvaro.
