Posts by heing

  • Cannot read serial port when input buffer contains exactly 9 bytes

    It is not possible to read data from serial port when input buffer contains exactly 9 bytes. The following code demonstrates the issue:

    Python
    1. from serial import Serial
    3. with Serial('/dev/ttymxc2', baudrate=115200, timeout=1) as serial:
    4. request = b'a' * 9
    5. serial.write(request)
    6. response = serial.read(9)
    7. assert request == response

    The number 9 is related to the length of the rx_fifo_trig in drivers/tty/serial/imx.c. For kernel 5.4.70, it was possible to set this value to 1 in the device tree, but for kernel 5.15.148, this didn't work for me anymore. The new work-around was to disable dma using the "no-dma" setting in device tree. Anyway, this seems like a bug in the serial port implementation which should be fixed.

  • After upgrade to Linux 5.15.148, SPI CS changes to active high

    Thanks. It did not make any difference for me, but what actually worked was changing the chip select to use GPIO instead of native chip select line:


    Code
    1. pinctrl_ecspi3_cs: ecspi3cs {
    2. fsl,pins = <
    3. /* ECSPI3_SS0 - slave (chip) select 0 */
    4. MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x1b0b0
    5. >;
    6. };

    Using GPIO instead of native chip select is also mentioned here:
    kernel.org/doc/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt


    I don't understand why the native chip selected suddenly changed to active high. The reason for using GPIO instead was not related to that. I really haven't looked into changing that though.


    Also, the fsl,spi-num-chipselects is obsolete and should be replaced by num-cs. If not, the value defaults to 3.

  • After upgrade to Linux 5.15.148, SPI CS changes to active high

    After upgrading to Linux 5.15.148, the chip select on spidev on ecspi3 goes high when active instead of low. I've tested using unmodified device tree files on armStoneA9r2q. Running on kernel 5.4.70 works fine. ecspi2 spidev seems to work as expected. Any reason why this would happen?


    Verified using downloaded F&S Kirkstone sdcard image and spidev_test.c application.

  • Serial port stops working after upgrade to kernel 5.4.70

    After some more investigation, I've found out that the problem depends on the length of the payload. I have short circuited RX and TX on port ttymxc2 and run the following python script (requires pyserial):


    Python
    1. from serial import Serial
    3. with Serial('/dev/ttymxc2', baudrate=115200, timeout=0.5) as serial:
    4. for i in range(100):
    5. request = b'a' * i
    6. serial.write(request)
    7. response = serial.read(len(request))
    8. if request != response:
    9. print(f'Length {i} failed')

    The code produces the following output:

    Length 9 failed

    Length 18 failed

    Length 27 failed

    Length 36 failed

    Length 45 failed

    Length 54 failed

    Length 63 failed

    Length 72 failed

    Length 81 failed

    Length 90 failed

    Length 99 failed


    All requests of length dividable by 9 are lost. This happens on kernel 5.4.70, but not on 4.1.15. Is anyone able to reproduce this behavior?

  • Serial port stops working after upgrade to kernel 5.4.70

    I have a sensor connected to /dev/ttymxc2 and this works fine with kernel 4.1.15. After upgrading to kernel 5.4.70, the communication stops working. The sensor uses a binary protocol with request and reply. After the upgrade, some of the replies from the sensor are lost, but some are still received. This is consistent. Certain commands always work and others never work. Typical for commands that doesn't work is that the delay before response is higher, 20-30ms.


    I've verified with an oscilloscope that the sensor sends the response.


    I use pyserial, but I've also verified the issue using stty and dd.


    Is there any reason why serial communication behaves differently in the two kernel versions? Kernel configuration and devicetree is unchanged.

  • Docker support on buildroot

    If you don't care about patches from F&S, you can use a vanilla Buildroot. Just use the F&S kernel. We use Buildroot version 2017.11.2 without any problems. I have also booted Debian 9 from sd card without much trouble, but I haven't had a chance to test it. Btw, official Debian 9 support would be cool and would enable us to run things like Azure IoT Edge on the board.

  • Unable to use PCIe

    Another question:


    The GPS sends the 1PPS signal on pin 42 (LED_WWAN) and pin 46 (LED_WPAN) on the Mini PCIe connector. Is any of these pins connected to the CPU so I can read it using GPIO?


    Kind regards,
    Hein Gustavsen
    Miros AS

  • Unable to use PCIe

    Thank you! I knew about the USB interface, but I was so caught up in the PCI error message that I did not think about trying USB. I had to enable USB_ACM in the kernel (USB Modem (CDC ACM) support) and then I got the /dev/ttyACM0 device as expected.


    Thank you for helping me resolve this issue!


    Kind regards,
    Hein Gustavsen
    Miros AS

  • Unable to use PCIe

    Quote from fs-support_DB

    Is the 1.5V voltage used by the module?


    Thank you for this tip. The GPS receiver does not use 1.5V as far as I can see.


    Our armStoneA9r2 does not provide 1.5V on the PCIe socket, but I guess that this is not the problem here. I will wait for you to test the PCIe interface and provide me with the correct kernel and device tree configuration.


    Kind regards,
    Hein Gustavsen
    Miros AS

  • Unable to use PCIe

    Jonas, did you manage to get the PCIe running?


    F+S: What is the current status for PCIe on armStoneA9r2? Do you have any patches or do you plan to include support in the upcoming release?


    I plan to use a PCIe GPS receiver (USB).


    Kind regards,
    Hein Gustavsen
    Miros AS