Alright this is my first post on this forum. I'll try to provide sufficient details but have mercy.
So I am trying to make an Arduino UNO (master) and a Teensy 4.1 (slave) communicate via SPI. More specifically, the UNO sends the Teensy a byte every second whereafter the Teensy prints the byte to the Serial monitor (I intend this to be some sort of MVP for a bigger project to make sure the communication works fine). Since slave mode is not officially supported for the Teensy 4.1 I am trying to make it work using this library by tonton81 https://github.com/tonton81/SPISlave_T4 and a forum post by tjaekel https://forum.pjrc.com/index.php?threads/teensy-4-1-spi-slave-here-it-is.72792/.
Unfortunately, I am having some issues with the data transmission, namely the Rx buffers do not seem to be filled although the Receive Data Flag (SR) is set properly.
First my setup:
- The Arduino runs in master mode
- The Arduino uses SPI mode 0
- MSB first
- Data is transmitted at 500kHz
This can also be seen in the sketch for the Arduino:
Wiring (UNO to Teensy), photo attached:
- Pin 13 to Pin 13 (SCK)
- Pin 11 to Pin 12 (MOSI, Note: According to tjaekel's post, the pins MOSI and MISO are swapped here)
- Pin 10 to Pin 10 (SS/CS)
- GND to GND
The problem:
As can be seen in the program (the code for the teensy including the library is attached) every time spiRxComplete is true the current
spiRxIdx should be printed to the Serial monitor. After that I expect the Teensy to print the already received bytes inside
spiRx. But for some reason the spiRxIdx always stays zero and this no bytes are printed. Still, after every transmission done by the Arduino the if-block executes (line 25) indicating that spiRxComplete is correctly set to true indicating further that RDF (SR) is set. So both the CLK and CS seem to be correctly received, only the MOSI line has some problems.
What I have already tried (without success):
- Changing the pin of the MOSI line on the teensy (although tjaekel's forum post specifies pin 12)
- Verified correct data transmission by the UNO using an oscilloscope (as can be seen in the pictures attached)
- Tried out different SPI modes (although the library hardcodes mode 0 from what I understand)
- Understand the library code (After a day of sitting behind the code and investigating into the i.MX RT1060X Processor Reference Manual I have already understood a lot more than before but I am certainly not experienced enough with low level programming to grasp every line of it. But I will certainly dig deeper!)
If somebody has an idea what could be wrong I would be very happy indeed!
Note: I have only marginally changed the code of the SPISlave_T4.tpp file so that the macro definitions for the register offsets use hex as in the reference manual because I consider that to be more readable when examining the code. But this should not change the behaviour at all (for safety I have even checked the whole setup with the original code).
So I am trying to make an Arduino UNO (master) and a Teensy 4.1 (slave) communicate via SPI. More specifically, the UNO sends the Teensy a byte every second whereafter the Teensy prints the byte to the Serial monitor (I intend this to be some sort of MVP for a bigger project to make sure the communication works fine). Since slave mode is not officially supported for the Teensy 4.1 I am trying to make it work using this library by tonton81 https://github.com/tonton81/SPISlave_T4 and a forum post by tjaekel https://forum.pjrc.com/index.php?threads/teensy-4-1-spi-slave-here-it-is.72792/.
Unfortunately, I am having some issues with the data transmission, namely the Rx buffers do not seem to be filled although the Receive Data Flag (SR) is set properly.
First my setup:
- The Arduino runs in master mode
- The Arduino uses SPI mode 0
- MSB first
- Data is transmitted at 500kHz
This can also be seen in the sketch for the Arduino:
C++:
#include <SPI.h>
#define SS_PIN 10
void setup() {
pinMode(SS_PIN, OUTPUT);
digitalWrite(SS_PIN, HIGH);
SPI.begin();
SPI.beginTransaction(SPISettings(500000, MSBFIRST, SPI_MODE0));
}
void loop() {
digitalWrite(SS_PIN, LOW);
delayMicroseconds(100);
SPI.transfer(0x42);
digitalWrite(SS_PIN, HIGH);
delay(1000);
}Wiring (UNO to Teensy), photo attached:
- Pin 13 to Pin 13 (SCK)
- Pin 11 to Pin 12 (MOSI, Note: According to tjaekel's post, the pins MOSI and MISO are swapped here)
- Pin 10 to Pin 10 (SS/CS)
- GND to GND
The problem:
As can be seen in the program (the code for the teensy including the library is attached) every time spiRxComplete is true the current
spiRxIdx should be printed to the Serial monitor. After that I expect the Teensy to print the already received bytes inside
spiRx. But for some reason the spiRxIdx always stays zero and this no bytes are printed. Still, after every transmission done by the Arduino the if-block executes (line 25) indicating that spiRxComplete is correctly set to true indicating further that RDF (SR) is set. So both the CLK and CS seem to be correctly received, only the MOSI line has some problems.
What I have already tried (without success):
- Changing the pin of the MOSI line on the teensy (although tjaekel's forum post specifies pin 12)
- Verified correct data transmission by the UNO using an oscilloscope (as can be seen in the pictures attached)
- Tried out different SPI modes (although the library hardcodes mode 0 from what I understand)
- Understand the library code (After a day of sitting behind the code and investigating into the i.MX RT1060X Processor Reference Manual I have already understood a lot more than before but I am certainly not experienced enough with low level programming to grasp every line of it. But I will certainly dig deeper!)
If somebody has an idea what could be wrong I would be very happy indeed!
Note: I have only marginally changed the code of the SPISlave_T4.tpp file so that the macro definitions for the register offsets use hex as in the reference manual because I consider that to be more readable when examining the code. But this should not change the behaviour at all (for safety I have even checked the whole setup with the original code).
