1 2 Previous Next 25 Replies Latest reply on Jul 3, 2017 5:10 PM by FerryT

    Multiple 0xFF returned after every transmission

    cyrillicsoft

      I’m using an Intel Edison for Arduino Board and the code for it is written in C++ using the Intel System Studio IOT Edition.

      I use mraa library functions (libmraa) to transmit and to read data to/from a device through the UART.

       

      The issue I'm facing is this: after every transmission through the UART (from Edison to the device), my following attempt to read data from the device results in a certain amount of 0xFF bytes after which I eventually receive the stuff I was expecting.

      If I carry out sequential reads one after another, the incoming data is received properly but once I transmit (write) something, a following read will bring me a bunch of these dubious 0xFFs.

      The device that I'm communicating with is not responsible for these bytes, it doesn't send them.

      So where might they be coming from? And how can I get rid of them?

        • 1. Re: Multiple 0xFF returned after every transmission
          Intel Corporation
          This message was posted on behalf of Intel Corporation

          Hi Cyrillicsoft,
           
          Thanks for your interest in the Intel® Edison platform.
           
          It is a strange behavior and we would like to know if you have checked the RX and TX signals using a logic analyzer or oscilloscope in order to know how those signals are behaving while you are writing and reading data from your Edison to your device. Doing that will help us in troubleshooting this issue.
           
          Regards,
          -Yermi A.
           

          • 2. Re: Multiple 0xFF returned after every transmission
            FerryT

            I think we may have seen something like that too (on the oscilloscope too). Have you tried powering off the edison and then back on (If I remember correct pressing the reset button was not enough).

            • 3. Re: Multiple 0xFF returned after every transmission
              cyrillicsoft

              Hi Yermi!

              I do have what you need for the input to Edison (RX) from the device I'm working with.

              I have no issues with the transmission itself.

              This effect of receiving a sequence of 0xFF for a read, executed after a write, only occurs when I work with a specific device (namely, a Nextion display).

              It's important to note that Nextion does not send these strange bytes and they are not on the wire (see diagram).

              I should also mention that this device emits a HIGH signal in idle mode.

               

               

              It might be worth mentioning that when I start a program on Edison, I get a 0xFC byte on the TX of UART0.

              Also, upon initializing any GPIO port, I likewise get a 0xFC byte on the TX of UART0. The initialization is done with the mraa_gpio_init() function of the mraa library.

               

              lead_cmd_trail_1A.png

              • 4. Re: Multiple 0xFF returned after every transmission
                FerryT

                cyrillicsoft it's coming back to me now. I think we had the problem when we were building with the sdk, which links to mraa 0.7.2. We fixed that by overriding the initialization in main.c by the code in hs_serial.c see GitHub - htot/hs_uart .

                 

                I think I read that this has been fixed in later versions of mraa. But instead I will be working to remove the dependency on mraa, so that this code will run on vanilla kernels as worked on by Andy Shevshenko GitHub - andy-shev/linux at eds

                • 5. Re: Multiple 0xFF returned after every transmission
                  Intel Corporation
                  This message was posted on behalf of Intel Corporation

                  Hi Cyrillicsoft,

                   

                   

                  Thanks for the information provided. We would like to investigate a little bit more and as soon as we have useful information we’ll let you know. We’ll appreciate your patience during the meantime.

                   

                  Additionally, Could you please try FerryT’s suggestions and keep us abreast of your results?

                   

                   

                  Regards,
                  -Yermi A.

                  • 6. Re: Multiple 0xFF returned after every transmission
                    cyrillicsoft

                    What FerryT has suggested is more or less what the "Using MRAA to Abstract Platform I/O Capabilities" book describes (this is a book by Integrated Computer Solutions, ics.com). I have already tried realizing this but it didn't help.

                    I found it a bit strange that the book recommended using the C read and write functions while working with the UART and not mraa_uart_read and mraa_uart_write functions...

                     

                    Nevertheless, I took hs_serial.c and used it to initialize the UART port. But nothing changed.

                     

                    I should reiterate the strange behavior I have been getting:

                    If I make sequential reads off RX, then all the data is read correctly.

                    If I transmit data through TX, then the following read will return a sequence of 0xFF followed by the expected data.

                    The amount of these 0xFF bytes is always a little larger than the amount of bytes I sent through TX. For example, the write sends 42 bytes and the read immediately after that returns 47 bytes. Moreover, I cannot see any mathematical dependency.

                     

                    In addition, I find it strange that I would receive a 0xFC on TX after starting a program and after every mraa_gpio_init() call.

                    • 7. Re: Multiple 0xFF returned after every transmission
                      FerryT

                      cyrillicsoft It is not that I am recommending to use mraa, in fact I will try to remove mraa dependencies from my code as soon as I can.

                       

                      We found that when using mraa 0.7.2 we had similar problems to yours: with tx looped back to rx, we were receiving many 0xFF chars, so many in fact that the received buffer overflows and eventually the Edison reboots (we were transmitting 2kB). BTW my colleague remembers it differently, he says the problems was caused *because* we were overflowing the tx buffer. Anyway, the 0xFF chars were actually transmitted and visible on the oscilloscope.

                       

                      As we did not have that manually initializing the serial port, we fall back to the routine in hs_serial.c (and increased the tx output buffer in the kernel from 2kB to 4 kB).

                       

                      BTW our GitHub - htot/hs_uart  transmits data periodically and the period needs to be set longer than the time to actually send the data.

                       

                      In most other protocols you would only transmit the next message after the receiver confirms reception. Or use XON/XOFF, or HW flow control.

                       

                      Further:

                      mraa_uart_read does not do much special.

                      0xFC is probably generated by toggling the TRI_STATE_ALL signal (is controlled by GPIO 214). This is done when setting up gpio (but also during uart init). Then this triggers a UART start bit causing a spurious char reception. So you need to setup all io's uart etc, open the uart and flush the buffer. But not change pin configuration after that point.

                      • 8. Re: Multiple 0xFF returned after every transmission
                        cyrillicsoft

                        My case is undoubtedly very similar to yours and I did find a software solution to it as I have done for the 0xFC issue which I handled just as you suggest.

                        Using XON/XOFF also solves all problems but it does demand that the device support the protocol.

                        Unfortunately, the Nextion display I'm working with does not have that capability and I really don't want to put it aside as it really simplifies the process of creating GUIs and works on just two wires.

                        The guys in China have sure made a very ingenious and handy device.

                        Concerning mraa, I didn't really choose it, it was recommended by Intel and since I've been familiar with it's products since '87, I've grown quite close to it. It would be upsetting if they do indeed disappoint...

                        I hold that it's easier to simply fix all of the weaknesses and flaws in mraa because there is nothing that you can't improve or correct. I hope Intel think likewise.

                        I'd also like to wait for Intel's reply on my issue.

                        • 9. Re: Multiple 0xFF returned after every transmission
                          FerryT

                          Have you tried upgrading mraa to a more recent version? I think the uart initialization problems have been solved in a later commit.

                          • 10. Re: Multiple 0xFF returned after every transmission
                            cyrillicsoft

                            My version is 1.5.1. Intel considers this to be the most suitable for Intel System Studio IoT.

                            • 11. Re: Multiple 0xFF returned after every transmission
                              Intel Corporation
                              This message was posted on behalf of Intel Corporation

                              Hi Cyrillicsoft,
                               
                              We would like to let you know that we are still working on it. Thanks for your patience.
                                                         
                              Regards,
                              -Yermi A.
                               

                              • 12. Re: Multiple 0xFF returned after every transmission
                                Intel Corporation
                                This message was posted on behalf of Intel Corporation

                                Hi Cyrillicsoft,

                                We did some tests using two Edisons and communicating them through the UART interface, the first Edison sent two messages to the second one and waited for a response, the second one received those messages and then sent the response to the first one. We checked the UART signals using a Logic analyzer and we have received the data successfully, we didn’t receive any 0xFFs.

                                 

                                This is the code we used: uart_sender.py and uart_receiver.py, we know that you are using C++ and in this code we are using Python, however, you could use them to test your Edison’s UART to discard any issues. Additionally, you can use that code as a reference to write your C++ code.

                                Regards,
                                -Yermi A.

                                • 13. Re: Multiple 0xFF returned after every transmission
                                  FerryT

                                  You might want to try doing the same with a message length > 2048 bytes (that is in one write).

                                  • 14. Re: Multiple 0xFF returned after every transmission
                                    cyrillicsoft

                                    Thanks for the time that you have put aside to help me.

                                    Of course, there is no difference whether I use Python or C++ because everything is eventually carried out by the OS.

                                    Your tests were always going to be successful because if they weren't, you'd have been flooded with questions similar to mine from other users about a faulty UART.

                                    My question was about Edison's behavior in a special case i.e. when it communicates with a Nextion display unit. In other words, these 0xFF bytes don't appear in ANY case you can think of, but in my specific setup (and maybe there are other possibilities).

                                    Obviously, you might not be able to check Edison's behavior with this device, I wasn't hoping that you would try to go to such lengths. I thought that just by describing my issue, using your experience, you might be able to advise me on what to do next and where the issue might possibly lie.

                                     

                                    If there are no concrete ideas, I'd like to ask this: what signal does Edison expect to receive while in idle mode? HIGH or LOW?

                                    1 2 Previous Next