I hope this email finds you well. I am writing to seek your assistance regarding an issue I am facing with the Cortex M4 on the Verdin iMX8M Mini module.
According to the instructions provided, after connecting a USB cable to the debug port X66,
I connected to the board by using COM13 via PUTTY
I should be able to see four ttyUSB ports on my Linux side by running the command ls /dev/ | grep ttyUSB*.
However, I have encountered a problem where no ttyUSB ports are being detected.
I have verified the connection between the Verdin development board and the host machine, ensuring that the USB cable is properly connected. Despite my efforts, I have been unable to resolve the issue on my own.
I would greatly appreciate your guidance in troubleshooting this matter. Could you please provide me with any suggestions or steps to follow in order to identify and resolve the problem? Alos, I have attached the output of dmesg. Recently, I installed TorizonCore 6, but there were no changes made to the Device Tree (DT).
This would be right when running this command on your Linux Host, after connecting the Verdin Development Board or Dahlia to your Host. You don’t even need to power it on to check for the ttyUSB* interfaces. On Yavia, there will be only 2 ttyUSB interfaces on your Linux Host.
But, from the image you shared, you are running this command on your Target (the Verdin module). Your target will not show the ttyUSB devices.
On Windows, seems like only 2 out of 4 Verdin Development Board ttyUSB are shown. And I am not aware of the cause of this.
I am in the step[ EXT4LOAD Loading Method] and I am using TorizonCore and placed your binary inside /var folder,
torizon@verdin-imx8mm-07219476:/var$ ls
cache hello_world.bin lib lock log rootdirs run sota spool tmp usrlocal volatile
How do I do step 3 Could you please explain it how to use U-Boot console?
Set up the loading command (load_cmd) with the ext4load command. As the loading procedure may be slightly different accordingly to the SoM, select it from the tabs below and follow the instructions:
Can you please provide an explanation and guide me on how to reach this U-Boot? Afterward, I’ll be able to use the “setenv” command and execute the commands.
You will mainly need access to the debug serial of the module. You will open a terminal into it (using applications like Putty, Minicom, Picocom, GTKTerm, etc) and keep pressing any key on this terminal as early as possible during the module’s boot. You will be dropped into the U-Boot’s prompt.
You will mainly need access to the debug serial of the module. You will open a terminal into it (using applications like Putty, Minicom, Picocom, GTKTerm, etc) and keep pressing any key on this terminal as early as possible during the module’s boot. You will be dropped into the U-Boot’s prompt.
I am sorry. I didn’t understand that this is what you needed.
Sorry for the bad explanation , the problem lies in my inability to access ttyUSB1_2_3_4 through minicom or other software. When I connect a USB Type-C cable to connector X66, I am presented with two COM ports, but unfortunately, the debugging port is non-functional.
COM12 is intended for communicating with the M4 and should be used for debugging purposes. Unfortunately, I am unable to execute commands through Putty or access it through minicom.
COM13 serves as the UART3 connection, allowing me to monitor the Linux side. It is utilized for communication with U-Boot and Linux and I can use that.
Please keep in mind that TorizonCore is built on top of Toradex’s BSP (also available as Yocto/OpenEmbedded layers). You should be able to follow the referred U-Boot article to access its prompt through serial.
This is the same serial interface (in your case, COM13) that you will use to access U-Boot’s prompt.
You won’t be able to use Cortex-M’s serial terminal as a common shell (e.g. Linux’s terminal). It doesn’t have this capability unless you implement it yourself for your use, but I guess this is not what you want to develop. You will be able to get Cortex-M’s messages once you load firmware into it that prints messages on its debug UART.