We are currently trying to get the UART3 running on the M4. After adding cases for UART3 in configure_uart_pins() / get_uart_clock_freq() it works now on the M4 when the linux kernel didn’t boot.
Issue is, after the linux boots there is just garbage on the UART3. It is already disabled in the device tree (before there was a kernel panic).
Additionally we found out, that if we wait with the initialization until the linux did boot it will work without issues. Any ideas what the issue could be?
This is likely due to clock changes in one of the parent clocks used by UART3. Linux probably changes frequency and/or clock source. With that the base clock of the UART will be different. If you initialize the UART from Cortex-M4 side after Linux booted, than the UART driver will likely use the new clock to calculate the baudrate…
The best solution is to use a clock which is not touched by Linux, e.g. the 24MHz main oscillator. The debug UART is using this clock too. You should be able to switch to that clock by using
CCM_UpdateRoot(CCM, ccmRootUart3, ccmRootmuxUartOsc24m, 0, 0);
See also dbg_uart_init in examples/imx7_colibri_m4/board.c.
We already use that clock. Additionally we tried to grab full access on the M4, but the issue remains.
CCM_ControlGate(CCM, BOARD_MODBUS_UART_CCM_CCGR, ccmClockNeededAll);
Instead of
CCM_ControlGate(CCM, BOARD_MODBUS_UART_CCM_CCGR, ccmClockNeededRunWait);
We tried also to switch the debug and modbus uart. If we do that the uart works and the debug not
Double check if UART3 is really disabled in the device tree. Maybe also check at the running system that Linux did not mux any of the required pads (in cat /sys/kernel/debug/pinctrl/pinctrl-handles).
Double checked the changes in the device tree. UART3 is disabled. As for the muxing of other pins please see the attached output pinctrl. We already tried to disable MX7D_PAD_UART3_RTS_B and MX7D_PAD_UART3_CTS_B without any effect. It also seems that they don’t actually belong to the pinctrl_uart3 as I see there only MX7D_PAD_UART3_TX_DATA__UART3_DTE_RX and MX7D_PAD_UART3_RX_DATA__UART3_DTE_TX.
Muxing indeed looks good. Did you try adding clk_ignore_unused to the kernel parameters?
Other than that I have no idea, I would have to reproduce it here to look into it. In case the above does not help, can you share your exact device tree changes and FreeRTOS firmware changes?
We have clk_ignore_unused always configured as default u-boot variable and we already checked that.
Just saw yesterday that since the update the usbg service doesn’t start anymore (see usbg). I also checked, before the change it worked. Does that maybe help you? If not we will create some small example that reproduces the error.
Also, is it possible to restrain access to the clocks used on the M4?
I tried some more things but couldn’t find anything. So I have prepared a minimal failing example. The debug version works as expected (else increase the loop counter a bit), the release version optimizes the fix away and has the issues.
On a quick glance all your changes seem good. Since the UART is clocked from the oscillator directly, I don’t see why the Linux BSP should influence the UART clock source.
I loaded the precompiled binary from release/uart_polling.elf and then run Linux using our regular 2.8b2 image (4.9 kernel) with the customized device tree. UART seems to work for me at all times. This is on a Colibri iMX7D V1.1B on a Colibri Evaluation Board V3.2B with UART_C conneted to UART_B…
Which Kernel/Linux BSP did you use?
We use a manually compiled version of the angstrom-lxde-image image on the LinuxImageV2.8 branch. Around 2 month old.
The kernel base is from the toradex_4.9-1.0.x-imx branch (commit b2a7f2f2fd3ec48b3d309111b6fe8ddee227539d, version 4.9.67)
One question regarding the device tree. Do I need to recompile the kernel / kernel modules after changes in the device tree?
Anyway, I will try to update all sources and do a clean build with yocto
No rebuild of the kernel/kernel modules is required. Just updating the device tree is sufficient.
Maybe there is some kind of a hardware issue? How do you check whether UART is working?