Posts by fs-support_HK

    OK, then you have downloaded a wrong NBoot file that was not suited for your board. You have to take care that you use the correct NBoot for your CPU architecture:


    • i.MX6 Solo/DualLite/Quad: nbootimx6_<version>.bin

      This is efusA9, armStoneA9, armStoneA9r2, PicoMODA9, QBlissA9, QBlissA9r2, NetDCUA9


    • i.MX6 SoloX : nbootimx6sx_<version>.bin

      This is efusA9X, PicoCOMA9X, PicoCoreMX6SX


    • i.MX6 UltraLite/ULL: nbootimx6ul_<version>.bin

      This is efusA7UL, PicoCOM1.2, PicoCOMA7, PicoCoreMX6UL


    Also note that you need to use binary mode to download such a file. In DcuTerm use "File" -> "Transmit Binary File...", in TeraTerm use "File" -> "Send file..." and check the "Binary" checkbox.


    Also as a general rule, do not downgrade NBoot. So for example if version VN35 is installed when shipped, do not downgrade to a version before VN35. There may be a hardware option installed on the board that was not supported by an earlier version of NBoot so that in the worst case the older version does not start, making the board unusable as in your case.


    So either send us the board to reinstall NBoot or use MfgTool yourself now to install NBoot again. Do you have instructions on how to do this?


    Your F&S Support Team

    What did you do? How did you remove NBoot?


    If you use our starterkit baseboard, the LEDs may show if some voltage is missing. Other than that your can check if there is display output or some other signal that toggles during the boot process or when your application is running,


    The <0> is not a specific signal. A board may show nothing at all but still responds to MfgTool.


    If you can not get the module running again, send it to us as RMA.


    Your F&S Support Team

    When using the EDT1 display adapter, the backlight of the LCD is controlled by an LED driver chip that is connected via I2C to the CPU. In newer software versions like on armStoneA9 we have integrated this as a backlight driver unit, but on armStoneA5 with the Vybrid kernel, this is only visible as the LED controller chip itself and has to be set manually.


    Go to the LED controller chip with

    Code
    1. cd /sys/bus/i2c/devices/3-0060/


    There you will find settings for 4 LEDs. The backlight brightness is controlled by led1. Each LED can be set to four values:


    0: fully off

    1: fully on

    2: controlled by individual PWM

    3: controlled by group PWM


    Our default setting is 1, i.e. fully on. You can show this by calling

    Code
    1. cat led1_output


    So the idea is to switch to PWM mode 2. But to avoid a sudden drop in brightness (the default PWM value is 0), set the brightness before switching the mode. Or simply set the PWM brigthness also to fully on, then switch the mode and then set the final brightness.

    Code
    1. echo 255 > led1_pwm
    2. echo 2 > led1_output

    From now on you can set any value between 0 and 255 to led1_pwm to control the brightness. Example:

    Code
    1. echo 60 > led1_pwm

    Your F&S Support Team

    VADC is something different, this is the analog video input (Video A/D Converter). So [2] is not relevant in this case.


    The device tree setting in [1] is actually all that needs to be set for ADC to work. There are two channels (ADC_A, ADC_B) on adc1 and two channels (ADC_C, ADC_D) on adc2. You will find the analog values in /sys/bus/iio/devices/iio\:device0 and /sys/bus/iio/devices/iio\:device1 respectively.


    BUT: On a regular efusA9X, the ADC channels are not connected. For some reason I also do not understand, a resistor network that connects the ADC channels to the connector pins is not mounted and therefore the input pins are floating. I have asked the hardware department for a reason and they will check. Maybe ADC will be available on future variants. But for now, ADC can not be used without hardware modification.


    Your F&S Support Team

    The USB protocol has a 16 bit value for the count of data blocks that can be transferred in one go. In other words up to 65535 data blocks with 512 bytes each, which is nearly 32MB. From the protocol, there are no restrictions given for this 16 bit value. However in real life, some USB sticks seem to have problems when the maximum value 65535 is used. Then they simply don't answer anymore, which results in USB protocol timeouts. From my point of view these USB sticks do not implement the protocol correctly.


    We have fixed this issue partly in the U-Boot that was part of the fsimx6-V3.0, fsimx6sx-V2.0 and fsimx6ul-V2.0 releases, by restricting the value to be used to 65534. This worked fine for a couple of USB sticks that we had by that time and that were showing this issue.


    Nonetheless I say partly, because we have observed a new issue with some USB sticks in the meantime. If the USB stick is very very slow, then reading and transferring these many blocks does take so much time that a data timeout happens. The timeout is set to a fix five seconds. So these slow sticks do need longer than 5 seconds to transfer 32MB of data, i.e. they can provide less than 54 MBit/s of data. USB 2.0 should be capable of delivering up to 480 MBit/s, so these sticks are really slow.


    So in the meantime, we have reduced the maximum number of blocks to transfer in one go further down to 32768 blocks. Up to now we did not have any problems anymore. However this fix was added after the last Buildroot releases (fsimx6-V3.1, fsimx6sx-V2.1, fsimx6ul-V2.1), but it is already part of the current Yocto releases (fsimx6-Y1.0, fsimx6sx-Y1.0, fsimx6ul-Y1.0). So if you want an U-Boot with this patch, download the Yocto release and extract the U-Boot source package from there.


    Of course for boards that are already in the field, you simply should use a stick that is 1) fast enough and that 2) can deliver 65535 blocks of data in one go. But do not ask me how you can decide this by just looking at the device...


    Your F&S Support Team

    Just a question, how do you enter commands if ttymxc3 is not working in both directions?


    What I did:


    Connect (loop-back) pins 3 and 5 of connector J6. Then


    Code
    1. stty -F /dev/ttymxc2 -echo -echoe
    2. cat < /dev/ttymxc2 &
    3. echo Hello > /dev/ttymxc2


    The "Hello" appears. Then I did the same for ttymxc3. However as this is the input line for commands, I used telnet to connect to the board instead.


    Code
    1. ifconfig eth0 10.0.0.252 up
    2. telnetd


    Then I started telnet on the PC:


    Code
    1. telnet 10.0.0.252


    After logging in, I unplugged the PC from connector J7 and looped back pins 3 and 5 instead. On the telnet connection I typed:


    Code
    1. stty -F /dev/ttymxc3 -echo -echoe
    2. cat < /dev/ttymxc3 &
    3. echo Hello > /dev/ttymxc3


    Again "Hello" appeared on the telnet screen.


    Your F&S Support Team

    We are working on the next release with newer kernel, newer Buildroot and newer U-Boot. But this will still take a few weeks. We will of course also have a look on Wayland again, so in the next release this should work out of the box.


    Your F&S Support Team

    OK, let's check something else. If you remove the PicoCOMA9X module from the baseboard, then you'll see two soldering jumper places on the baseboard itself, i.e. two semi-circle shaped pads close to each other so that they can be connected by putting some solder on them. Here the jumper next to the two capacities should be open and the jumper in direction to the PicoCOM connector should be closed (connected). There are also pads for a small 8-pin IC next to this second jumper, this IC should not be mounted.


    If there is something different, then please tell me.


    Do you have a second hardware to compare the behavior?


    Your F&S Support Team

    Just to be sure: Terminal input (like ttymxc in this case) is line buffered. so you will not see the input data until you press Return on the PC side. If you do not want this, you have to change the tty settings on the board side to raw mode using stty.


    And also note that each character is echoed, which may have funny effects if you connect two ttys together: one character is sent, the other side echoes the character, the local side echoes the character again, and so on, resulting in an endless sequence of characters to be transferred in both directions. If you do not want this, you have to disable this echo with stty.


    Your F&S Support Team

    Do you use the serial adapter and null-modem cable that was provided in the starter kit? Did you configure the serial connection in the terminal program on the PC side correctly? 115200 baud, 8 data bits, 1 stop bit, no flow control. For example using flow control on the PC side when RTS/CTS is not active on the PicoCOM side may cause such behavior. Then the PC may think that the board is not ready to receive data due to the uninitialized and therefore incorrect state of the RTS line of the board (=CTS on the PC side).


    If you use a different connection and/or configuration, please tell us.


    Your F&S Support Team

    Ok, we have checked this. Actually Buildroot and Yocto use a different CAN utilities package. Buildroot uses the can-utils package from linux-can on github, Yocto is using the canutils package (without dash) from Pengutronix. Both packages provide commands candump and cansend, but they use a different syntax.


    can-utils (Buildroot):

    Code
    1. cansend can<n> <id>#<bytesequence>


    <n> number of can port
    <id> either 3 or 8 hex digits for short or extended ID
    <bytesequence> 2 to 16 hex digits representing the data bytes of the message


    canutils (Yocto):

    Code
    1. cansend can<n> -i <id> <byte> <byte> <byte> ... <byte>


    <n> number of can port
    <id> ID, must use prefix 0x to be in hex
    <byte> One byte of message; must use 0x to be in hex


    To send the same message on Yocto, you have to use the following command.


    Code
    1. cansend can0 -i 0x456 0x43 0x41 0x4e 0x20 0x54 0x65 0x57 0x74


    Actually we weren't aware of this difference, too, so thanks for pointing this out.


    Your F&S Support Team

    I have tried to verify this issue. I extracted Buildroot, called make fsimx6_qt5_defconfig and then called make menuconfig to add the extra packages that you mentioned. Finally I called make. If I look into my rootfs now, I do find the plugin as /usr/lib/qt/plugins/sqldrivers/libqsqlpsql.so. So here it works fine.


    This PostgreSQL Plugin is part of qt5-base. So if you had Qt5 already built, before you enabled the plugin, then you need to call


    Code
    1. make qt5base-reconfigure


    before the next build. Alternatively rebuild everything from scratch.


    Your F&S Support Team