Related to the other question I put on this forum (and some other devices where SPI fails to work) I decided to check with my logic analyzer what was going on with my SPI communication. I have two MM Teensy reproducing the same behaviour on the ATP board from Sparkfun and the analyser (one of those cheap knockoff ones) attached. No other ports used.
Code is taken from the example on the pjrc.com website, and adapted to use only one device, I wanted to make as few changes as possible, even though it doesn't provide a meaningful example. CS Pin used is 55 on MM Teensy.
Now for the issue:
Looking at the graph from PulseView (please see attachment) it doesn't seem to correlate at all with what I am expecting to see from the code provided as I would be expecting the CS Pin (SS in Pulseview) to stay low until transmission has been finished. I might be wrong, but can someone please explain if I am doing something wrong or if there's something to look for? I'd really like to get SPI working on this device. Happy to provide more examples I tried and where I see similar behaviour.

Code is taken from the example on the pjrc.com website, and adapted to use only one device, I wanted to make as few changes as possible, even though it doesn't provide a meaningful example. CS Pin used is 55 on MM Teensy.
Code:
#include <SPI.h> // include the new SPI library:
// using two incompatible SPI devices, A and B
const int slaveBPin = 55;
// set up the speed, mode and endianness of each device
SPISettings settingsB(16000000, MSBFIRST, SPI_MODE0);
void setup() {
// set the Slave Select Pins as outputs:
pinMode (slaveBPin, OUTPUT);
// initialize SPI:
SPI.begin();
}
uint8_t stat, val1, val2, result;
void loop() {
// read three bytes from device A
if (stat == 1) {
result = val1;
} else if (stat == 2) {
result = val2;
} else {
result = 0;
}
// send result to device B
SPI.beginTransaction(settingsB);
digitalWrite (slaveBPin, LOW);
SPI.transfer(result);
digitalWrite (slaveBPin, HIGH);
SPI.endTransaction();
}
Now for the issue:
Looking at the graph from PulseView (please see attachment) it doesn't seem to correlate at all with what I am expecting to see from the code provided as I would be expecting the CS Pin (SS in Pulseview) to stay low until transmission has been finished. I might be wrong, but can someone please explain if I am doing something wrong or if there's something to look for? I'd really like to get SPI working on this device. Happy to provide more examples I tried and where I see similar behaviour.
