Hi,
I have tried to use UART3 of IMX6D for communication with TiWi-uB2 chip.
In U-Boot i set up UART3 pins as
static iomux_v3_cfg_t const uart3_pads[] = {
IOMUX_PADS(PAD_SD4_CMD__UART3_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
IOMUX_PADS(PAD_SD4_CLK__UART3_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
IOMUX_PADS(PAD_EIM_D30__UART3_CTS_B | MUX_PAD_CTRL(UART_PAD_CTRL)),
IOMUX_PADS(PAD_EIM_D31__UART3_RTS_B | MUX_PAD_CTRL(UART_PAD_CTRL)),
};
in kernel's device tree i setup pins as:
pinctrl_uart3: uart3grp {
fsl,pins = <
MX6QDL_PAD_SD4_CMD__UART3_TX_DATA 0x1b0b1
MX6QDL_PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
MX6QDL_PAD_EIM_D30__UART3_CTS_B 0x1b0b1
MX6QDL_PAD_EIM_D31__UART3_RTS_B 0x1b0b1
>;
};
Also in U-Boot i additionally set IOMUX regs which selects RX and RTS pins for proper UART
/* select UART3 RX pad */
writel(3, 0x020E0930 );
/* select UART3 RTS pad */
writel(3, 0x020E092C );
So everything looks as described in docs.
With oscilloscope i can see that hciattach sends some of bytes to BT chip and also i can see that BT chip is answering with some of data.....but hciattach finished with
Initialization timed out.
So looks like it can not receive data from BT chip (i suspect). Also a small possibility that RX pin ball on package has bad contact or similar mounting problems.
But before dismounting of chip from PCB i'd like to be sure that i setup UART pins correctly.
Is it enough for IMX6D settings that i did to make UART ready to receive data?
WBR,
Hi Egor
uart can be tested with uart unit test, checking signals with oscilloscope:
mxc_uart_test\test - imx-test - i.MX Driver Test Application Software
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi, Igor.
Thank you for your message. But i suppose that this test can help to test UART logically as it use internal loopback. Seems that it is mean to loop tx reg to rx reg.
In my case i see physical problems - may be i did wrong RX pin settings or may be pin has bad contact.
The worst case is to cut off traces RX/TX to bletooth chip by knife and short rx on tx. Or dismount IMX chip from PCB.
So that is why i want to be sure that i setted up RX pin correctly form IMX point of view.
WBR,
Here is test output:
./mxc_uart_test /dev/ttymxc2
---- Running < ./mxc_uart_test > test ----
/dev/ttymxc2 opened
Attributes set
Test: IOCTL Set
Data Written= Test
Data Read back= Test
---- Test < /dev/ttymxc2 > ended ----
As i said in previous message logically UART is working. I used other PCB for test, so probability of bad soldering is going to sezo.
Seems something wrong with pinmux settings.
So could someone advise is it enough to set
IOMUX_PADS(PAD_SD4_CLK__UART3_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL))
in U-boot
and
MX6QDL_PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
in kernel's device tree
and also
/* select UART3 RX pad */
writel(3, 0x020E0930 );
UART3 device has described in device tree as:
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3>;
status = "okay";
};
is enough to set up SD4_CLK pin as UART3 RX function?
PS:
root@DIPP7_imx6sl:/tmp# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
1: uart:IMX mmio:0x021E8000 irq:289 tx:1517 rx:126 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x021EC000 irq:290 tx:10 rx:6 CTS|DSR|CD
3: uart:IMX mmio:0x021F0000 irq:291 tx:0 rx:0 DSR|CD
root@DIPP7_imx6sl:/tmp# hciattach /dev/ttymxc2 texas
Initialization timed out.
root@DIPP7_imx6sl:/tmp# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
1: uart:IMX mmio:0x021E8000 irq:289 tx:2055 rx:152 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x021EC000 irq:290 tx:14 rx:6 CTS|DSR|CD
3: uart:IMX mmio:0x021F0000 irq:291 tx:0 rx:0 DSR|CD
Here we can see that after loopback test rx of ttymxc2 has 6 bytes received, but after hciattach no bytes received (oscilloscore shows at least 2 bytes on rx line)
WBR,
I found solution. It is very non usual for me but....
&usdhc4 {
status = "disabled";
};
hellped to solve issue