Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 19 of 19

Thread: Teensy 3.6 SPI problem with Teensyduino 1.40 but not 1.35

  1. #1
    Junior Member
    Join Date
    Dec 2017
    Posts
    10

    Teensy 3.6 SPI problem with Teensyduino 1.40 but not 1.35

    We have some SPI code which works when built with Arduino 1.8.1 / Teensyduino 1.35 but fails (apparently either reads the wrong data, but hard to be certain) when built with Arduino 1.8.1 / Teensyduino 1.40 and when build with Arduino 1.8.5 and Teensyduino 1.40

    We're running on a Teensy 3.6, we've repeated the experiment when building on Windows 7 & on Linux.

    I can't post the code as-is, but i can make a cut-down sample if that would help.

    Are there any known issues with SPI and Teensyduino 1.40 ? I'm new to the Teensy world, I may not have looked in all the right places.

    And, is there any way to get hold of a Mac installer for 1.35, that being the platform I really need to build this on now... :-)

    Thanks,

    Richard

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,432
    Might help to know more information, like are you using standard pins or alternate pins? Anything else special?

    Obviously seeing the code would help to debug.

  3. #3
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,457
    The biggest change between TD 1.35 and TD 1.40 is most probably the newer toolchain, using C++14 now instead of C++11 before. This should normally not be a problem if your code is clean and state of the art. If parts of your code were problematic under this aspect, you‘d have seen compiler warnings and you had most probably fixed your code already.

    If your code compiles in TD1.40 without warnings, and SPI still does not work, I‘d really like to see a code snipped which allows to reproduce the problem, preferably using a MOSI/MISO loop whee the sent data will immediately be read back and verified with what was just sent.

  4. #4
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Thanks, both. I'll see if I can get the problem to show in a smaller snippet.

    No, no warnings, and nothing leaps out at me as suspicious in the code.

    In the meantime, do you have any idea where I might find TD 1.35 for Mac ?

    Thanks,

    Richard

  5. #5
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,099
    Quote Originally Posted by jarkman View Post
    In the meantime, do you have any idea where I might find TD 1.35 for Mac ?
    https://www.pjrc.com/teensy/td_135/T...inoInstall.dmg

  6. #6
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Just a quick partial update - looking at the SPI traffic with my Salaea, it looks as though the 1.35 builds are sending/receiving the expected 8 bytes from the code below, the 1.40 builds are sending & receiving 3 bytes. I'm an SPI noob, so this may well yet be something ridiculous in the code. Anyhow, code and screenshot:

    I'll see if I can make a standalone sample that demonstrates the problem.

    Code:
    digitalWrite(slaveSelectPin,LOW);
    delayMicroseconds(1);
    for (i=0; i<8; i++)
    	inbuffer[i] = SPI.transfer(outbuffer[i]);
    delayMicroseconds(1);
    digitalWrite(slaveSelectPin,HIGH);
    SPI setup is

    Code:
    pinMode (slaveSelectPin, OUTPUT);
    digitalWrite(slaveSelectPin,HIGH);
    SPI.begin();
    SPI.setBitOrder(MSBFIRST);
    SPI.setClockDivider(SPI_CLOCK_DIV4);
    SPI.setDataMode(SPI_MODE1);

    Click image for larger version. 

Name:	Screen Shot 2017-12-07 at 18.35.59.jpg 
Views:	33 
Size:	69.1 KB 
ID:	12184

  7. #7
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Here's a screenshot of the same code built with 1.35 for comparison:
    Click image for larger version. 

Name:	Screen Shot 2017-12-07 at 18.47.38.jpg 
Views:	33 
Size:	68.6 KB 
ID:	12185

  8. #8
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,432
    Quote Originally Posted by jarkman View Post
    Here's a screenshot of the same code built with 1.35 for comparison:
    Click image for larger version. 

Name:	Screen Shot 2017-12-07 at 18.47.38.jpg 
Views:	33 
Size:	68.6 KB 
ID:	12185
    Not sure what is going on in your case.
    I tried this, based off of your code above:
    Code:
    #include <SPI.h>
    #define slaveSelectPin 10
    void setup() {
      Serial.begin(115200);
      pinMode (slaveSelectPin, OUTPUT);
      digitalWrite(slaveSelectPin, HIGH);
      SPI.begin();
      SPI.setBitOrder(MSBFIRST);
      SPI.setClockDivider(SPI_CLOCK_DIV4);
      SPI.setDataMode(SPI_MODE1);
    }
    
    uint8_t outbuffer[8]= {0, 1, 2, 3, 4, 5,6, 7};
    uint8_t inbuffer[8];
    
    void loop() {
      digitalWrite(slaveSelectPin, LOW);
      delayMicroseconds(1);
      for (uint8_t i = 0; i < 8; i++)
        inbuffer[i] = SPI.transfer(outbuffer[i]);
      delayMicroseconds(1);
      digitalWrite(slaveSelectPin, HIGH);
      delay(10);
    }
    I ran it on a T3.6 using current SPI stuff. My version is current with Paul's. The latest change was to allow pin 45 as a Chip select pin.

    Here is the output from logic Analyzer.
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	29 
Size:	55.6 KB 
ID:	12187

    You might want to check to see if you have a different version of SPI library sitting around. In particular in your <arduino sketch folders>/libraries/SPI

  9. #9
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Interesting! Will experiment further and report back. Thanks.

  10. #10
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,386
    the sketch in post #8 works for me on T3.5 (1.8.4/1.40), MISO jumpered to MOSI. Verified with logic analyzer, too.
    Click image for larger version. 

Name:	spitmp1.jpg 
Views:	25 
Size:	116.5 KB 
ID:	12188

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    I also tried the code from message #8, with the very latest (unreleased/github) Teensyduino code. Here's what I see.

    Click image for larger version. 

Name:	file.png 
Views:	28 
Size:	43.9 KB 
ID:	12190
    (click for full size)

    This is yet another case where I need to remind about the "Forum Rule". When you post only code fragments, someone (Kurt in this case) has to do extra work to fill in the rest of the code. This almost always results in not reproducing the problem.

    Please, do yourself a favor, post a COMPLETE program in your message. It will help us get to the bottom of the problem you're seeing. Complete programs save everyone's valuable time. Otherwise we just waste effort testing code that don't really reproduce the problem, and writing more messages. All that effort could have gone into actually finding and fixing whatever is really wrong. Please please please, follow the Forum Rule by posting a complete program that anyone can copy and paste into Arduino and run the exact same thing you tested. Don't make us have to guess the rest of the code!

  12. #12
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    Looking at the screenshots, this might be a simple case of the test gear sampling too slowly.

    I see only 5 MHz in messages #6 & #7. Kurt used 25 MHz in message #8. Manitou used 16 MHz in message #10. My oscilloscope sampled at 2500 MHz.

    Comparing the images in #6 and #7, it looks like Teensyduino 1.35 used a slower SPI clock. The data spans ~50 microseconds in #7. All of our tests with version 1.40, even #6, show the data spanning ~18 microseconds with Teensyduino 1.40.

    The 5 MHz sampling setting used in #6 is much too slow for this faster SPI data rate.

  13. #13
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Sorry, my bad with the sample. Thank you all for your help.

    I've just done a bit more leisurely a/b testing, and confirmed both of Paul's suspicions.

    This is running Kurt's sample (with MOSI and MISO connected to our test hardware, not wired together), and with the Salaea sampling faster.

    Building with 1.35 on Windows 7, I get an SPI clock at 1.25MHz
    Click image for larger version. 

Name:	teensy_1_35_karl_1_25_mhz.jpg 
Views:	14 
Size:	72.1 KB 
ID:	12219

    Building with 1.40 on OSX, I get a clock at 3.8MHz
    Click image for larger version. 

Name:	teensy_1_40_karl_3_86_mhz.jpg 
Views:	14 
Size:	75.0 KB 
ID:	12220

  14. #14
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Doing it with the transaction API, thus:

    #include <SPI.h>
    #define slaveSelectPin 10

    SPISettings settingsA(2000000, MSBFIRST, SPI_MODE1);

    void setup() {
    Serial.begin(115200);
    pinMode (slaveSelectPin, OUTPUT);
    digitalWrite(slaveSelectPin, HIGH);
    SPI.begin();
    //SPI.setBitOrder(MSBFIRST);
    //SPI.setClockDivider(SPI_CLOCK_DIV4);
    //SPI.setDataMode(SPI_MODE1);
    }

    uint8_t outbuffer[8]= {0, 1, 2, 3, 4, 5,6, 7};
    uint8_t inbuffer[8];

    void loop() {
    SPI.beginTransaction(settingsA);
    digitalWrite(slaveSelectPin, LOW);
    //delayMicroseconds(1);
    for (uint8_t i = 0; i < 8; i++)
    inbuffer[i] = SPI.transfer(outbuffer[i]);
    SPI.endTransaction();
    digitalWrite(slaveSelectPin, HIGH);
    delay(10);
    }

    I get good behaviour with both

    1.35

    Click image for larger version. 

Name:	teensy_1_35_transactions_2mhz.jpg 
Views:	14 
Size:	78.7 KB 
ID:	12223

    and 1.40:

    Click image for larger version. 

Name:	teensy_1_40_transactions_2_mhz.jpg 
Views:	14 
Size:	73.1 KB 
ID:	12224
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	teensy_1_35_transactions_2_mhz.jpg 
Views:	14 
Size:	77.7 KB 
ID:	12221   Click image for larger version. 

Name:	teensy_1_40_transactions_2_mhz.jpg 
Views:	14 
Size:	71.6 KB 
ID:	12222  

    Last edited by jarkman; 12-10-2017 at 09:49 AM. Reason: fixing screenshots

  15. #15
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    And, applying the new API to our original code brings it back to working in 1.40! Which means I'm very happy, we can get back to work.

    Just to get to the end of the story, is the underlying clock rate that the old API divides down actually different in 1.40 ?

    Thanks, all!

    Richard

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,029
    Confirmed, the old versions when used with only the legacy SPI functions where generating wrong (too slow) clocks.

  17. #17
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,432
    Also I find if you need to run your Saleae at lower speeds, it shows SPI data up when your capture rate is a multiple of the actual rate that the bits are generated. Not sure if that makes sense.

    So what I am trying to say is, if you are asking to generate a signal at 2mhz, the SPI code says this is the maximum it is allowed to generate and it will choose the fastest speed up to what you asked for.

    So if you are running at the default 180mhz, the buss speed is set to 60mhz. If you ask for 2mhz, the default code looks for the right setting. So it checks:
    Code:
    ...
    				t = SPI_CTAR_PBR(0) | SPI_CTAR_BR(3) | SPI_CTAR_CSSCK(2);
    			} else if (clock >= F_BUS / 20) {
    				t = SPI_CTAR_PBR(2) | SPI_CTAR_BR(1) | SPI_CTAR_CSSCK(0);
    			} else if (clock >= F_BUS / 24) {
    				t = SPI_CTAR_PBR(1) | SPI_CTAR_BR(3) | SPI_CTAR_CSSCK(2);
    			} else if (clock >= F_BUS / 32) {
    				t = SPI_CTAR_PBR(0) | SPI_CTAR_BR(4) | SPI_CTAR_CSSCK(3);
    ...
    So it checks (Note I am reducing numbers here): if (2 >= 60/24) NO... is 2 >= 60/32 Yes... So actual speed is: 1.875mhz...

    Now suppose you instead configure the T3.6 to run at 192mhz, which has the default bus speed of 48mhz. So from above:
    if (2 >= 48/24) YES - And it generates exactly 2mhz signal.

    So for example if you can probably capture reasonably well at 2mhz, but for sure at 4mhz...

    and sort of out of off topic, but yesterday I discovered that Saleae had released newer updates 1.2.17... Which included some very nice speed improvements for their PRO versions.

  18. #18
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Quote Originally Posted by PaulStoffregen View Post
    Confirmed, the old versions when used with only the legacy SPI functions where generating wrong (too slow) clocks.
    Great, thanks for the confirmation.

  19. #19
    Junior Member
    Join Date
    Dec 2017
    Posts
    10
    Thanks. I was only running too slow because I hadn't noticed what it was set to, will try not to make that mistake again! :-)

    Wonder if they could provide some visual cue that you're near the limit, sloping edges on the logic signals or some such ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •