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

Thread: T4 SPI mode0 transmit bug?

  1. #1

    T4 SPI mode0 transmit bug?

    Greetings!

    I've been diving into SPI recently and I wonder if I may have found a bug with the SPI library as implemented for the T4? In SPI mode 0 the data are sampled on the rising edge of the clock. So, data transitions coincident with the clock's rising edge may or may not work depending on the exact details of the edges, and that shouldn't be allowed.

    I noticed that SPI mode 0 writes looked odd on the T4, so I compiled and ran the code below on both the T4 and T3.6 (Teensyduino 1.49). The 'scope traces show that the first rising clock edge is coincident with a data transition for the T4, but the T3.6 looks good.

    In both 'scope images chip select is pink, clock is yellow, and data is blue. Note that the data transitions coincident with the first clock edge on the first image (T4). Is this a bug, or am I missing something?

    cheers,
    Doug


    Code:
    #include "SPI.h"
    uint8_t payload=0;
    
    void setup()
    {
      Serial.begin(115200);
      delay(5000);
      pinMode(10, OUTPUT);
      SPI.begin();
    }
    
    void loop()
    {
      SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
      digitalWriteFast(10, LOW);
      Serial.println(SPI.transfer(payload));
      Serial.println(payload);
      payload++;
      digitalWriteFast(10, HIGH);
      SPI.endTransaction();
      delay(2000);
    }
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	DS0001.PNG 
Views:	12 
Size:	20.4 KB 
ID:	19496   Click image for larger version. 

Name:	DS0002.PNG 
Views:	9 
Size:	20.9 KB 
ID:	19497  


  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Yes, this does not look OK.
    Might be needed to have look at the registers if there is a way to fix this.

  3. #3
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Hm, but I can't confirm this:

    Click image for larger version. 

Name:	pic_31_1.png 
Views:	4 
Size:	15.7 KB 
ID:	19498
    (clk yellow, data cyan)

    My code is more simple:
    Code:
    #include "SPI.h"
    
    void setup()
    {
      SPI.begin();
    }
    
    void loop()
    {
      SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
      SPI.transfer(0x80);
      SPI.endTransaction();
    }
    It is a "perfect" Mode 0 - Data valid at rising edge of clk (cpol=0, cpha=0)


    Click image for larger version. 

Name:	arduino_fullduplex_spi_tranmission.png 
Views:	2 
Size:	24.4 KB 
ID:	19499

  4. #4
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Even better to see with a added delay(1) to the end of the loop:
    Click image for larger version. 

Name:	pic_31_2.png 
Views:	5 
Size:	15.3 KB 
ID:	19500

  5. #5
    I reproduced your example, but try sending 0x70 instead. I think that shows the problem.

    Click image for larger version. 

Name:	DS0003.PNG 
Views:	3 
Size:	22.0 KB 
ID:	19503

  6. #6
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Indeed - yes, I get the same now
    I wonder whats wrong here.. I hope no silicon bug..

    Edit: the errata does not mention such a bug: https://www.nxp.com/docs/en/nxp/errata/IMXRT1060CE.pdf
    So, let's assume it's a configuration issue.

  7. #7
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    With increasing timing resolution (8 ns) it looks a little bit better:
    Attachment 19504
    (first bit of 0x70 - yello: clock, cyan: data)
    Still - that's a bit tight

  8. #8
    Hmm, I can't see your attachment...

  9. #9
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Click image for larger version. 

Name:	pic_31_4.png 
Views:	6 
Size:	15.8 KB 
ID:	19505
    attachment - again

  10. #10
    Yikes! While that might work ok in many environments it looks to me like it's being timed from the wrong edge...

  11. #11
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Might be something like this, yes...

  12. #12
    I was just looking at the NXP MK66 datasheet, because I'm really more focused on the T3.6 SPI interface for now. The spec for data setup time is 15.8nS, so that timing shown in your figure is right on the edge, even for a Teensy 3.6.

    So I reckon this is something that should be fixed. My skills are lacking in this domain, or I'd go poking around myself.
    cheers,
    Doug

  13. #13
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    Please try this:

    change line 1208 https://github.com/PaulStoffregen/SP...er/SPI.h#L1208 in SPI.h to this:
    Code:
                _ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2) | LPSPI_CCR_PCSSCK(div/2);
    What do you think, does it fix it?

  14. #14
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,276
    I am curious, could this be relevant to doing multiple SPI accesses while toggling the CS concurrently (back to back) within the same transaction, causes data collission/corruption of some sort as experienced in my MCP23S17 library, where 2 solutions were to A) use a 50uS delay or B) end the transaction and start a new one?

    Reference: https://forum.pjrc.com/threads/59909...025#post232025

  15. #15
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    maybe yes...
    not sure what this does in your case, tonton, but if the change above does not help, you can try to add this (line 1208):
    Code:
                _ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2) | LPSPI_CCR_PCSSCK(div/2) | LPSPI_CCR_SCKPCS(div/2);
    It looks like yor're not using the hardware-chipselect but the PCSSCK seems to influence the time nevertheless - perhaps SCKPCS does the same? I've not tested this.

    Edit: Yes, on the scope it looks better.

  16. #16
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578
    again, SCK is yellow, Data the other.
    Click image for larger version. 

Name:	pic_31_5.png 
Views:	4 
Size:	19.2 KB 
ID:	19507

    Good night. Too late here.
    I'll do a PR tomorrow.

  17. #17
    Member
    Join Date
    Feb 2018
    Location
    Corvallis, OR
    Posts
    60
    Is this the same problem that we hashed out in https://forum.pjrc.com/threads/59906...ght=spi+timing

    I found the the issue with the late activation of MOSI can be solved by adding PCS to SCK delay. I also posted the code to fix the problem in SPI.beginTransaction.

  18. #18
    Frank, yes, I agree it looks correct now in my testing too. I'm not really using T4 SPI, but I'm glad my observation may have helped you fix something.
    Thanks very much,
    Doug

  19. #19
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,578

Posting Permissions

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