I am experiencing challenges with displaying output via UART-B after flashing a hello_world.elf example to the Cortex-M4 of a Colibri iMX7 module using a Colibri Evaluation Board V.3.2b. Below are the details of my setup and the steps I’ve followed:
Setup:
Host Machine: MacBook M2
Target: Colibri iMX7 on Colibri Evaluation Board V.3.2b
Connections:
UART-A: Connected via USB-B to USB-A cable, plugged into the X27 connector. Output to the console is visible here.
UART-B: Connected via a DB9 male-male pass-through cable linked to a RS232 Female DB9 to USB-A cable to my laptop. This setup is connected to the RS-232 Top on connector X25. The serial port connects, but no output is visible.
Steps to Reproduce:
Building the Example: Successfully built the hello_world example, generating hello_world.elf in freertos-colibri-imx7/examples/imx7_colibri_m4/demo_apps/hello_world/armgcc/debug.
Preparing the SD Card: Formatted an SD card to FAT32 and loaded the hello_world.elf.
Booting and Loading in U-Boot:
Detected and set SD card as the device in U-Boot.
Listed and identified the correct partition.
Executed the following commands in U-Boot:
Colibri iMX7 $ mmc list
FSL_SDHC: 1
FSL_SDHC: 0 (eMMC)
Colibri iMX7 $ mmc dev 1
switch to partitions #0, OK
mmc1 is current device
Colibri iMX7 $ part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 8192 62349312 00000000-01 0b
Colibri iMX7 $ fatls mmc 1:1
.Spotlight-V100/
.fseventsd/
536871012 hello_world.elf
4096 ._hello_world.elf
Loaded hello_world.elf into memory and tried to execute it:
Starting auxiliary core stack = 0x00000000, pc = 0x1FFF807D...
Colibri iMX7 $ go ${loadaddr}
## Starting application at 0x84200000 ...
Issue:
I am unable to see any output from the hello_world application on UART-B; the terminal remains blank despite successful commands and load indications in U-Boot.
How can I confirm that the Cortex-M processor was flashed successfully?
Could anyone please advise on possible reasons for the lack of output on UART-B and suggest any debugging steps I could take to resolve this issue? Any assistance would be greatly appreciated.
Would you mind loading the binary again, but by follow the guidance here including, set and saving loadaddr = 0x80800000 It looks like your application is starting at a different address.
Rebooted the board and entered U-Boot. I made sure the binary was located in the /ostree/deploy/torizon/var directory, and ran through the setup commands to load the binary through U-Boot:
Looks like the Aux core stack is still starting at 0x0000. How could I resolve this issue ?
UART-B still does not output anything. Do I have to make modifications to the Linux Device Tree as outlined here, in order to see the correct output ? I can’t seem to find the colibri-imx7_disable-uart-b_overlay.dtbo UART-B disable device tree overlay file outlined here.
Additional debug information:
Tried debugging the issues by doing the following:
Execute the ELF file load command to verify there are no issues: ext4load mmc 0:1 0x84200000 /ostree/deploy/torizon/var/hello_world.elf
Thanks for the detailed report back. Everything looks correct.
Have you disabled UART_B in the device tree for the Linux side? Also are you using BSP 6?
From the previous linked article…
Load and Run the Firmware on Cortex-M4
…
" By default, our Linux device tree uses UART_B too, which leads to an external abort when the Linux kernel tries to access UART_B. It is recommended to alter the device tree and disable UART_B using the status property, which can be done by applying device tree overlays."
I have not modified the device tree to disable UART-B (uart2) yet, and was wondering if you have the compiled UART-B disable device tree overlay file colibri-imx7_disable-uart-b_overlay.dtbo as outlined here: How to Run a Hello World on the Cortex-M | Toradex Developer Center
Following this link for directions. You should already have the .dtbo on the device, the hyperlink should take you to the directions on how to enable the overlay, to disable to UART_B.
Not a problem, given a .dtbo file I know how to apply the overlay. But the colibri-imx7_disable-uart-b_overlay.dtbo file indicated in the documentation does not exist on the Colibri IMX7:
I ran the following sudo find / -iname "*.dtbo" | grep -i "uart-b" on the Colibri IMX7, and the file did not exist on the device. Is there a repo that contains this compiled device tree overlay file: colibri-imx7_disable-uart-b_overlay.dtbo
When loading the hello_world.elf using the following m4boot env: m4boot=ext4load mmc 0:1 0x84200000 /ostree/deploy/torizon/var/hello_world.elf; dcache flush; bootaux 0x84200000, there was still no output over UART-B and the auxiliary core stack = 0x00000000:
When loading the hello_world.bin using the following m4boot env: m4boot=ext4load mmc 0:1 0x84200000 /ostree/deploy/torizon/var/hello_world.bin; dcache flush; bootaux 0x84200000, there was still no output over UART-B, but the. auxiliary core stack was non 0x0:
## No elf image at address 0x84200000
## Starting auxiliary core stack = 0x20008000, pc = 0x1FFF8311...
This effort is just to validate if the Colibri IMX7 platform is usable for a larger scale project that will implement CAN bus communication via FreeRTOS on the M4, and pass information to the Linux application on the A7 core. Based on this simple demo, our team will continue with the evaluation of this system,
After talking with one of our domain experts. I have more information on what does/does not work.
The information for adding the .dtbo file[file found here] is specific to our downstream BSP 5 image. So this device tree addition will not actually allow FreeRTOS on the mcore to work on the upstream BSP 6.
The Colibri IMX7 is fully upstream supported. Currently the FreeRTOS we have on the Toradex github is a downstream NXP fork, which is not compatible with the upstream. It may be possible to fork the upstream FreeRTOS and make it work, but this hasn’t been tested yet.
There is the possibility of using Zephyr as an alternative as well.
Thank you for the detailed update. I have a couple of questions to help clarify the next steps:
Regarding the BSP version, what would you recommend as the best course of action? Should I continue using the upstream BSP 6 for its broader support and compatibility, or switch back to the downstream BSP 5 which seems more tailored to our current configurations and the .dtbo file for FreeRTOS on the mcore?
If we consider using Zephyr as an alternative, would we still need to create a device tree overlay file specifically to deactivate UART-B for Linux? How would this process differ from our current setup with FreeRTOS in terms of handling device tree configurations?
I’m trying to determine the most efficient path forward that minimizes compatibility issues and maximizes the performance of our applications. I am leaning towards reverting to BSP 5, and then setting up FreeRTOS based on what is available currently from the Toradex github. Let me know what you think.
You’ve brought up the better points between BSP 5 and 6. BSP 5 is still a LTS release, and is used on new builds specifically for cases such as this where support is more defined. BSP 6 and this model should eventually gain support, but I don’t think anyone could give a date on this. If FreeRTOS is a larger driving factor, I would say BSP 5 is the correct way to go.
Thanks for the help @eric.tx - will pursue BSP 5 + FreeRTOS, and create a seperate thread for any issues if required. For now we can close this thread.