Hi
With my Colibri setup, i ran into another problem with the new image. The modbus communication has stopped working.
&uart0 {
status = "okay";
linux,rs485-enabled-at-boot-time;
dma-names = "", "";
};
As far as i can see, the default pinmux group should be ok. Therefore further settings in iomuxc:
&iomuxc {
pinctrl-0 = <&pinctrl_hog_1>;
vf610-colibri {...};
};
uart0 will show up as /dev/ttyLP0, as expected.
For modbus the project makes heavy use of libmodbus. This was implemented on LinuxImageV2.6b2 using libmodbus_3.1.2.
Now with the new Image i will get tons of Connection timed out, Resource temporarily unavailable or Connection reset by peer errors, depending on the setup used. In a few cases, some reads went through, meaning i did not get an error but received an answer of the expected size.
As i’m new to the topic, i don’t really understand what is going on. I added pinctrl_hog_1 because i2c-1 did not work with hog_0. So maybe that is the problem again?
UPDATE
When accessing the Interface with a RS485 to USB converter from the outside, no Data is sent in either direction:
1. screen /dev/ttyUSB2 57600
2. echo "foo" > /dev/ttyLP0
screen does not show any output…
So there is no communication at all?
Can you double check that all involved pins are properly muxed? The debugfs can be helpful, check cat /sys/kernel/debug/pinctrl/pinctrl-handles. Check that the uart0grp contains all involved pins.
Maybe the RS485 transceiver needs additional pins?
Hi Stefan
Thank you for your reply. I did not know about the debugfs. Here is the output of the relevant device. What more Pins could it need? rx/tx + CTS/RTS
device: 40027000.serial current state: default
state: default
type: MUX_GROUP controller 40048000.iomuxc group: uart0grp (16) function: vf610-colibri (0)
type: CONFIGS_PIN controller 40048000.iomuxc pin VF610_PAD_PTB10 (32)config 000021a2
type: CONFIGS_PIN controller 40048000.iomuxc pin VF610_PAD_PTB11 (33)config 000021a1
type: CONFIGS_PIN controller 40048000.iomuxc pin VF610_PAD_PTB12 (34)config 000021a2
type: CONFIGS_PIN controller 40048000.iomuxc pin VF610_PAD_PTB13 (35)config 000021a1
Pins should be Rx:33, Tx:35, RTS:27 and CTS:25. What more pins could there be?
Pins seem to be ok, according to this document
This is the Original groups i believe:
PTB12 and PTB13 are in two goups.
pinctrl_uart0: uart0grp {
fsl,pins = <
VF610_PAD_PTB10__UART0_TX 0x21a2
VF610_PAD_PTB11__UART0_RX 0x21a1
VF610_PAD_PTB12__UART0_RTS 0x21a2
VF610_PAD_PTB13__UART0_CTS 0x21a1
>;
};
pinctrl_hog_2: hoggrp-2 {
fsl,pins = <
VF610_PAD_PTB12__GPIO_34 0x22ed
VF610_PAD_PTB13__GPIO_35 0x22ed
>;
};
Usually RS485 uses the TX/RX and the RTS signal, so this looks good (unless your Carrier Board connects RS485 somehow differently)…
Both 2.6 and 2.7 uses the Linux 4.4 kernel, so there are no huge changes in the Kernel in general. I checked the kernel difference between 2.6Beta2 and 2.7b4, there are some changes regarding DMA and fixes, but nothing which seems directly related to RS485:
git log -p Colibri_VF_LinuxImageV2.6Beta2_20160701..Colibri-VF_LXDE-Image_2.7b4-20171005 drivers/tty/serial/fsl_lpuart.c
To rule out any hardware/user space issue I would recommend use a working setup (module etc), and only update kernel/device tree to 2.7b4…
Will try, but takes some time to build an old one from scratch.
PREFERRED_PROVIDER_virtual/kernel-module-mcc = "kernel-module-mcc-toradex"
PREFERRED_PROVIDER_virtual/kernel-module-mcc-dev = "kernel-module-mcc-toradex"
PREFERRED_VERSION_mqxboot = "1.%"
Is it possible that this kernel module is necessary?
root@colibri-vf:~# lsmod
Module Size Used by
virtio_rpmsg_bus 11524 0
usb_f_rndis 15546 2
u_ether 11913 1 usb_f_rndis
vf610_rpmsg 4302 0
virtio 7411 2 virtio_rpmsg_bus,vf610_rpmsg
virtio_ring 10919 2 virtio_rpmsg_bus,vf610_rpmsg
libcomposite 43508 10 usb_f_rndis
configfs 23781 3 usb_f_rndis,libcomposite
root@colibri-vf:~# lsmod
Module Size Used by
usb_f_rndis 16039 2
u_ether 11881 1 usb_f_rndis
usb_f_acm 5083 2
u_serial 9188 1 usb_f_acm
libcomposite 43775 12 usb_f_acm,usb_f_rndis
configfs 22037 4 usb_f_acm,usb_f_rndis,libcomposite
First, lsmod of the new image, and second lsmod of the old image. I see that u_serial is not loaded, but than again much is different here.
UPDATE
Not exactly sure how i can only update the Kernel to 2.7. Is there a repo command?
I tried updating zImage and dtb on the SDCard, which results in either a Segmentation fault or a glibc mismatch when i try to start my application.
Also it cannot be a Hardware Issue, since the old software on the old image on the same hardware.
As for there is no communication: Also with the Old image (the working one) i could not communication through the adapter. There may be another problem there.
The MMC modules are only required if you are using the secondary M4 core on Colibri VF61.
In 2.7 we moved away to provide USB serial emulation (CDC ACM), that is why u_serial is not loaded.
The easiest way is to just manually replace zImage and vf610-colibri-eval-v3.dtb on the SD-card. E.g. first prepare the SD card with the old release. Then replace the two files from the new release on the generated card in the colibri_vf folder.
The glibc issue sounds more like a version missmatch between glibc and the user space application of the old image… Did that run with the old kernel/device tree?
Hi
Sorry, i did not see the comment yesterday since it was folded. Anyhow thats what i found out so far:
OLD Image:
SW Works, No Signal on rs485-to-USB adapter
OLD Image with new zImage and dtb:
SW Works, No Signal on rs485-to-USB adapter
NEW Image with same SW as aboge
SW does not work, No Signal on rs485-to-USB adapter
Is it possible to verify the flash process to make sure the right zImage and dtb are used? The utility does not always flash everything.
Hm, so it seems that using the RS485 to USB converter even did not work back when the application used to work fine? So there is some other issue with the RS485 to USB converter test is probably…?
Given that the application works with the old image and the new zImage/dtb your issue seems to be related to a user-space component, would you agree with that conclusion?
In that case, I would suggest to start replacing individual components. Probably an obvious candidate is libmodbus. You should be able to find a ipk file in the deploy/ directory, it might be worth to just try installing the new library in the old image. If this starts to causing issue, then libmodbus is to blame…
Yes it does seem to be a user space problem. My custom init layer does this:
systemctl stop serial-getty\@ttyLP0
systemctl disable serial-getty\@ttyLP0.service
I will try reducing my own code as far as possible, but i doubt somehow that it will help. Only in recipes_init is something related to ttyLP0. The rest just adds new files and does not override anything.
Yes. it looks like that was it. I cannot look into it further today, but after disabling serial-getty by hand, again, the debug messages change. Looks primising!
Update
Ok. so the above mentioned service seems to always restart, thus the problem always came back. Masking the service like so, seems to do the trick:
Instead of:
systemctl stop serial-getty\@ttyLP0.service
systemctl disable serial-getty\@ttyLP0.service
Do:
systemctl mask serial-getty\@ttyLP0.service
systemctl stop serial-getty\@ttyLP0.service
I think systemd generates a serial-getty service automatically from the kernel command line, even after disabling the service. I think if you remove console=ttyLP0... from the kernel command line, systemd would not generate the service.
I’m trying to change include/configs/colibri_vf.h, but i cant seem to get it right. Either i got a Kernel panic, preventing the boot, or some services fail after the boot.
Where would i remove this console=ttyLP0?
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -176,7 +176,7 @@
NFS_BOOTCMD \
SD_BOOTCMD \
UBI_BOOTCMD \
- "console=ttyLP0\0" \
+ "console=tty0\0" \
"defargs=\0" \
"dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
"fdt_board=eval-v3\0" \
Updated code above
