Modbus CRC errors, rs485 extensions on Neuron

Achilleas Kotsis

Hello,
After upgrading to the latest kernel modules and modbus tools, there seems to be an issue with rs485 communication with serial devices.

Sending a "turn on coil" command through rs485 produces the following communication output on /dev/ttyNS0

< 0x01 ([SOH])
< 0x05 ([ENQ])
< 0x00 ([NUL])
< 0x00 ([NUL])
< 0xff (�)
< 0x00 ([NUL])
< 0x8c (�)
< 0x3a (:)
> 	0x01 ([SOH])
> 	0x05 ([ENQ])
> 	0x00 ([NUL])
> 	0x00 ([NUL])
> 	0xff (�)
> 	0xff (�)
> 	0x00 ([NUL])
> 	0x8c (�)
> 	0x3a (:)

In the reply from the serial extension, the byte "0xff" seems to be duplicated. This doesn't happen on the physical layer, attached decoded communication using an oscilloscope. Also, other types of communications don't seem to be affected (turn off coils, read inputs etc).

Package versions:

root@basementplc:~# dpkg -l | grep unipi
hi  unipi-common                          1.2.30                               armhf        Common utilities for Unipi/Neuron/Axon
hi  unipi-firmware                        5.52                                 all          Firmware files for UniPi Neuron/Axon boards
hi  unipi-firmware-tools                  1.2.30                               armhf        Firmware utilities for UniPi Neuron/Axon controllers.
hi  unipi-kernel-modules-dkms             1.62                                 all          UniPi Neuron/Axon kernel modules - DKMS source
hi  unipi-modbus-tools                    1.2.30                               armhf        Modbus server for UniPi Neuron/Axon controllers.
root@basementplc:~# uname -a
Linux basementplc 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux

Achilleas Kotsis

Seems like 0xff gets duplicated in the response even if it is part of the CRC

< 0x01 ([SOH])
< 0x01 ([SOH])
< 0x00 ([NUL])
< 0x00 ([NUL])
< 0x00 ([NUL])
< 0x0e ([SO])
< 0xbd (�)
< 0xce (�)
> 	0x01 ([SOH])
> 	0x01 ([SOH])
> 	0x02 ([STX])
> 	0xf4 (�)
> 	0x00 ([NUL])
> 	0xff (�)
> 	0xff (�)
> 	0x3c (<)

martin_triska

Hello @Achilleas-Kotsis ,

thank you for your detail report!

We check this and will get back. With the previous version of unipi-kernel-modules package, the issue never appears?

How did you simulate the issue in the listing above? By a loopback using the other serial?

Achilleas Kotsis

I used interceptty to create a pty that logs and passes through to the serial port. I don't know the exact version number where it broke, but definitely happened after I last upgraded, previously it was working OK. Currently using a usb->rs485 adaptor and everything works as expected.

Martin Kudláček

Hello @Achilleas-Kotsis,
the issue is not with the unipi-kernel-module, but with the unipi-firmware 5.52. We have removed it from our repository and advise to downgrade to 5.50 (and flash it to the HW via /opt/unipi/tools/fwspi). We are working on the fix.

Thank you again for reporting this issue and have a nice day,
Martin