7 Replies Latest reply on Apr 26, 2017 2:32 PM by Intel Corporation

    SPI (speed) problems

    JelleRoets

      Recently I updated the firmware of one of my edisons to the latest image ("201606061707") However with this new firmware the spi behaves incorrectly (and different than before the update with firmware version "weekly-159") with certain spi frequencies.

       

      In my test environment I connected an SPI device to my intel edison breakout board, set the speed to 400 kHz and monitored the physical connection using a scope. I used a c++ snippet like the following, using mraa v1.5.1

        Spi spi(0);
        spi.mode(SPI_MODE0);
        spi.frequency(400e3);
      
        uint8_t command[] = { 0b10101100, 0b01010011, 0, 0 };
        uint8_t rxBuf[4];
        if (spi.transfer(command, rxBuf, 4) == SUCCESS) {
             printf("Writing [%#02x, %#02x, %#02x, %#02x]\n", command[0], command[1], command[2], command[3]);
             printf("Received [%#02x, %#02x, %#02x, %#02x]\n", rxBuf[0], rxBuf[1], rxBuf[2], rxBuf[3]);
        } else {
             cout << "Error\n";
        }
      

      I double checked the connections and verified the signals on my scope: the clk line seems to correctly produce a 400 kHz clock signal, also the correct waveforms (representing the given data bytes) are set on the MOSI line, also on the MISO line my spi device set the expected data bytes, in sync with the clock line. However the data that I received in my rxBuffer in software doesn't correspond to the signals I can see on the scope.

      - When I replace this edison with another one still containing the older firmware ("weekly-159") without changing any connection and with exactly the same program, I do get the correct data bytes in my rxBuffer.

      - When I change the frequency to 1 MHz, on the edison with the new firmware, I also get the correct results!

      - Also with the new firmware, a program that does not use the c++ mraa lib, but directly writes to the linux spidev device seems to have the same issue

      => So to me this looks like with the new firmware, setting the spi frequency correctly sets the clock period and the output data but fails to set the correct input sample speed...

      Can someone (from intel) verify this behaviour and try to fix it? Since it is very confusion and very hard to find out why this is not working as expected!

       

      Other issues I had while trying to use the linux spidev (most of them already have other threads):

      - There only seems to be a linux spidev5.1 device while according to the hardware specs of the edison, there are 2 separate chip select lines. So the other CS line can only be controlled manually.

      - Since there is only 1 spidev device it always toggles the connected CS line, also when I don't want to. Which makes it impossible to use more than 1 device on the same spi bus: E.g. I have one spi device with a CS connected to the edison's FS0 (GP110) port and another device on the same bus but with his CS connected to FS1 (GP111) port. Even if I simply implement the manual toggling of the first CS line, using spidev5.1 will always toggles the FS1 port as well. So the only solution is using 2 totally different ports and implement them manually as the correct CS lines and leave the FS1 port unconnected. So you'll lose one GPIO port only because of a software issue (which is unacceptable IMHO)

       

      So I hope Intel will take a closer look at the spi functionality (not unimported for a IoT device!) thoroughly test it and fix all of these issues. Thanks in advance

        • 1. Re: SPI (speed) problems
          Intel Corporation
          This message was posted on behalf of Intel Corporation

          Hi JelleRoets,

          Thank you for contacting us.

          We really appreciate this post, and we are going to test it.

          To replicate the issue we need the code that you are using, or the necessary files to test it under the same conditions, to check if we get the same problem.

          We will be waiting for your reply.

          Regards,
          -Leonardo
           

          • 2. Re: SPI (speed) problems
            JelleRoets

            To give you some more context about my project: I'm trying to use the edison as an atmel AVR programmer, using the popular open-source software avrdude.

             

            So according to atmel datasheet, you can serially program the flash and EEPROM of atmel AVR microcontrollers, see AN: http://www.atmel.com/Images/Atmel-0943-In-System-Programming_ApplicationNote_AVR910.pdf

            So in order to do so: I connect the microcontroller (in my case an AT90USB646: http://www.atmel.com/images/doc7593.pdf ) serial programming port with the spi bus of the edison (breakout board), using a level shifter (TXB0104 | Bidirectional Voltage Translation | Voltage Level Translation | Description & parametrics)  to convert the voltage levels from the edison gpio 1.8V to the 5V supply voltage of my AVR. Next I connect the pulled-up reset pin of the avr with a transistor to the edison, as well as a the supply of the AVR (to dynamically switch power to my AVR on and off).

             

            According to the AN - section 3.2, the first thing to check if the AVR is responding is sending a program enable instruction and see if it acknowledges, hence I've written a very simple program to send the program enable instruction and read the device id: see attachment for full c++ program (like noted above I used the latest mraa version 1.5.1). If the device is responding, the second program enable instruction byte (0x53) should echo back.

            If I run this program on my edison (with the new firmware) and the spi speed set to 400 kHz, I get the following incorrect results: my receive buffer sometimes contains 0x30, while this byte is never set on the physical MISO line: see scope image

            DwengoTestboard-01:~# chmod 755 /home/root/bin/programmer;/home/root/bin/programmer;exit 
            Programming spi speed: 400000 Hz
            Writing [0xac, 0x53, 00, 00]
            Received [00, 0x30, 0x30, 0x30]
            Writing [0x30, 00, 0x1, 00]
            Received [00, 00, 00, 00]
            Writing [0x30, 00, 0x2, 00]
            Received [00, 0x30, 0x30, 0x30]
            

            scope_1.png

            However when I run this program with the spi speed set to 1 MHz, I get the following correct results

            DwengoTestboard-01:~# chmod 755 /home/root/bin/programmer;/home/root/bin/programmer;exit
            Programming spi speed: 1000000 Hz
            Writing [0xac, 0x53, 00, 00]
            Received [00, 00, 0x53, 00]
            Writing [0x30, 00, 0x1, 00]
            Received [00, 0x30, 00, 0x96]
            Writing [0x30, 00, 0x2, 00]
            Received [00, 0x30, 00, 0x82]
            

            scope_2.png

            Also I noted that actually every spi speed < 1 MHz gives incorrect input results, while all speeds >= 1 MHz (until 3 MHz, max programming speed) do give the correct results.

             

            Once this programming test works, I can upload a .hex file to my AVR using avrdude. To do so I found an avrdude fork which uses the linux spidev interface to send the programming instruction here: GitHub - kcuzner/avrdude: avrdude with a Linux SPI programmer type  . After checking out this code on my edison and compile and build avrdude for the edison, I had to fill out the correct gpio pin, spidev and spi speed in the avrdude configuration file (for details see Raspberry Pi as an AVR Programmer | Projects & Libraries and my comment to adopt this procedure for the edison)

            Note the default avrdude spi speed was 400 kHz, hence my first try which actually doesn't work, like described above.

            At last, changing this speed to 1 MHz made it finally possible to use my edison as full blown avr programmer

            • 3. Re: SPI (speed) problems
              Intel Corporation
              This message was posted on behalf of Intel Corporation

              Hi JelleRoets,

              Thank you for the information provided, we are going to test it, and we are going to reply you soon.

              Have a nice weekend.

              Regards,
              -Leonardo

              • 4. Re: SPI (speed) problems
                Intel Corporation
                This message was posted on behalf of Intel Corporation

                Hi JelleRoets,

                I just want to let you know that we are still working on this.

                Thank you for your patience.

                Regards,
                -Leonardo

                • 5. Re: SPI (speed) problems
                  Intel Corporation
                  This message was posted on behalf of Intel Corporation

                  Hi JelleRoets,

                  We have verified this issue, and I just want to let you know that this issue is in consideration for a future releases of Edison software.

                  Thank you for your patience.

                  Regards,
                  -Leonardo

                  • 6. Re: SPI (speed) problems
                    JelleRoets

                    Hi Leonardo,

                     

                    Do you have any information about the status of the above issues?

                    Is there already a new release of the Edison software and are the issues mentioned solved? if so which issues?

                     

                    Best regards,

                    Jelle

                    • 7. Re: SPI (speed) problems
                      Intel Corporation
                      This message was posted on behalf of Intel Corporation

                      Hi JelleRoets,

                      There is not a new software release yet, but thanks to you we are aware of this issue. Hopefully, it will be fix in future software releases.

                      Thanks for your patience.

                      Regards,
                      Leonardo R.