No Output on UART-B After Flashing hello_world.elf to Cortex-M on Colibri iMX7

[mit]

Hello Toradex Community,

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:

1. 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.
2. Preparing the SD Card: Formatted an SD card to FAT32 and loaded the hello_world.elf.
3. 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:

Colibri iMX7 $ fatload mmc 1:1 ${loadaddr} hello_world.elf

164404 bytes read in 10 ms (15.7 MiB/s)

Colibri iMX7 $ dcache flush
Colibri iMX7 $ bootaux ${loadaddr}

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?

Articles Followed:

1. FreeRTOS on Cortex-M4 of Colibri iMX7
2. How to Load Binaries on Cortex-M of Colibri iMX7
3. Running FreeRTOS on NXP i.MX7Dual Cortex-M4F

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.

Thank you!

[mit]

@jeremias.tx was wondering if I could get your support on this topic after your help with the following: Colibri Evaluation Board w/ Colibri IMX7D 1GB System on Module setup issues

[eric.tx]

Hey @mit,

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.

In your

[mit]

Hi @eric.tx ,

I’ve re-run through the steps outlined here: How to Load Compiled Binaries into Cortex-M | Toradex Developer Center

I specifically I did the following:

1. Formatted my SD card to EXT4 format and loaded in the built hello_world.elf binary file.
2. Entered the Torizon OS and copied the binary from the SD card to: /ostree/deploy/torizon/var/hello_world.elf
   
   
3. 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:
   
   

Note: I confirmed that my m4boot commanded was formatted with a non 0x0 address:

$ printenv m4boot
m4boot=ext4load mmc 0:1 0x84200000 /ostree/deploy/torizon/var/hello_world.elf; dcache flush; bootaux 0x84200000

Issues I am still running into:

• 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:

1. Execute the ELF file load command to verify there are no issues: ext4load mmc 0:1 0x84200000 /ostree/deploy/torizon/var/hello_world.elf
   
   
2. Verified that the memory address 0x84200000 contained reasonable data: md.b 0x84200000 100
   Outputs:

84200000: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00  .ELF............
84200010: 02 00 28 00 01 00 00 00 7d 80 ff 1f 34 00 00 00  ..(.....}...4...
84200020: 74 7e 02 00 00 04 00 05 34 00 20 00 03 00 28 00  t~......4. ...(.
84200030: 18 00 17 00 01 00 00 00 a0 00 00 00 00 00 00 00  ................
84200040: 00 00 00 00 40 02 00 00 40 02 00 00 04 00 00 00  ....@...@.......
84200050: 20 00 00 00 01 00 00 00 e0 02 00 00 00 80 ff 1f   ...............
84200060: 00 80 ff 1f 20 2b 00 00 20 2b 00 00 07 00 00 00  .... +.. +......
84200070: 20 00 00 00 01 00 00 00 00 2e 00 00 00 00 00 20   ..............
84200080: 00 00 00 20 64 00 00 00 e8 58 00 00 06 00 00 00  ... d....X......
84200090: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ...............
842000a0: 00 80 00 20 7d 80 ff 1f 9d 80 ff 1f 9d 80 ff 1f  ... }...........
842000b0: 9d 80 ff 1f 9d 80 ff 1f 9d 80 ff 1f 00 00 00 00  ................
842000c0: 00 00 00 00 00 00 00 00 00 00 00 00 45 8e ff 1f  ............E...
842000d0: 9d 80 ff 1f 00 00 00 00 d5 8e ff 1f 35 8f ff 1f  ............5...
842000e0: 9d 80 ff 1f 9d 80 ff 1f 9d 80 ff 1f 9d 80 ff 1f  ................
842000f0: 9d 80 ff 1f 9d 80 ff 1f 9d 80 ff 1f 9d 80 ff 1f  ................

7f 45 4c 46 indicates that the bytes are a valid ELF header.
3. Verified all the environment variables were set properly:

Best,
Mit

[eric.tx]

Hey @mit,

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."

Can you confirm this was done as well?

-Eric

[mit]

Hi @eric.tx ,

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

Best,
Mit

[eric.tx]

Hey @mit,

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.

-Eric

[mit]

Hi @eric.tx ,

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

Best,
Mit

[eric.tx]

Hey @mit,

Working on getting this, there may be some information on our guides that need updating. I will report back as soon as I can.

-Eric

[mit]

Hi @eric.tx ,

Thanks for looking into this further. In the mean time I tried the following:

1. Instead of building the binaries, I used the hello_world.elf and hello_world.bin files from: https://files.toradex.com/Colibri/FreeRTOS/Binaries/Colibri-iMX7-M4_FreeRTOS_1.2-20170407.zip
2. 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:
   
   
3. 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,

Best,
Mit

[eric.tx]

Hey @mit,

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.

-Eric

[mit]

Hey @eric.tx ,

Thank you for the detailed update. I have a couple of questions to help clarify the next steps:

1. 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?
2. 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.

Note: Enabling communication using ZephyrOS doesn’t seem to be a straightforward task as outlined here: openamp_rsc_table App in imx7d-pico (M4-Side name in Zephyr=pico_pi_m4) I cant see /dev/ttyRPMSG · Issue #69433 · zephyrproject-rtos/zephyr · GitHub

Thanks,
Mit

[eric.tx]

Hey @mit,

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.

On Zephyr, you may find similar requirements for setup are needed, Toradex doesn’t test/validate. But we do contribute to the Zephry community… For Colibri IMX7 see:
https://docs.zephyrproject.org/latest/boards/toradex/colibri_imx7d/doc/index.html

From this I would lean towards BSP 5 + FreeRTOS. (as my personal advice)

-Eric

[mit]

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.