Confusing (to me) SPI results T4.1

csreades

Active member
EDIT: It seems these issues are something to do with the hardware I am using. For some reason when plugged in the teensy only sends half the packets it needs to. Without changing the program and removing the hardware it send the full number of packets. This is true for MODE0 or MODE2. What hardware issue can cause this behaviour?







I am having confusing issues with the T4.1 when using SPI. I am not seeing all the packets being transmitted in certain cases.


3 transactions in a loop repeating once, total of 6 bytes, 0xFF, 0x00, 0xFF, 0xFF, 0x00, 0xFF. What was actually sent was 0xFF, 0xFF, 0x00.
Code:
#include <SPI.h>

void setup() {
  // put your setup code here, to run once:
  pinMode(15, OUTPUT);
  SPI.begin();
}

void loop() {
  // put your main code here, to run repeatedly:
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE2));
  byte zero = 0x01;
  byte full = 0xFF;
  byte out = 0;
  digitalWriteFast(15, LOW);
  for (int k = 0; k < 2; k++) {
    out = SPI.transfer(full);
    out++;
    //delayMicroseconds(9);
    out = SPI.transfer(zero);
    out++;
    //delayMicroseconds(9);
    out = SPI.transfer(full);
    out++;
    //delayMicroseconds(9);
  }
  digitalWriteFast(15, HIGH);
  SPI.endTransaction();
  delay(1);
}

Code1.jpg

The code as above with the delay uncommented leads to:

withdelay.jpg

4 transactions, 0xFF, 0xFF, 0xFF, 0xFF and two delays (should be 6).






Done some more testing now. Thought I would try a non-blocking call (which I want in the end). Copied some code from the forums.

Code:
#include <SPI.h>

EventResponder callbackHandler;

void setup() {
  // put your setup code here, to run once:
  pinMode(15, OUTPUT);
  SPI.begin();
  
callbackHandler.attachImmediate(&callback);
}

#define arrLength 16

void loop() {
  // put your main code here, to run repeatedly:
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE2));
  byte zero[arrLength];
  for(int k = 0; k < arrLength; k++){
    zero[k] = k * 1;
  }
  digitalWriteFast(15, LOW);
  SPI.transfer((void *)zero, nullptr, arrLength, callbackHandler);
  digitalWriteFast(15, HIGH);
  delay(1);
}


void callback(EventResponderRef eventResponder)
{
  //end screen update
  SPI.endTransaction();
}

I set the array to count in binary, on my scope I can see the first 8 packets no problem, and correctly counting up. So I am even more confused now.
 
Last edited:
Thanks for confirming. It seems to be the logic level shifters I had in my circuit caused the issue. But I don’t understand how hardware can change the teensy operation?
 
out of curiosity, can you try this?
put it AFTER SPI.begin()
Code:
#if defined(__IMXRT1062__)
    IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_01 = IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; /* LPSPI4 SDI (MISO) */
    IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_02 = IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; /* LPSPI4 SDO (MOSI) */
    IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 = IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; /* LPSPI4 SCK (CLK) */
    IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_00 = IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; /* LPSPI4 PCS0 (CS) */
#endif

see what the scope shows?
 
Apologies tonton81, I can try that out but when I thought it was a hardware issue I snipped off the shifter and soldered on a 74HC541. I don't have the issue anymore, so my shifter was part to blame (like this https://www.sparkfun.com/products/12009 - for reference this is a terrible design for any signal over 1kh[which I assume everyone but me knew]). I do have some other PCBs with the original shifter on but not with me, I will try that out next time I have access to them?
 
yeah, its just for curiosity, we had an issue with SPI talking to an SPI slave T4 and this ressolved it, if it can fix other stuff since you have a scope it can be a good reference to look back on
 
Back
Top