Based on my somewhat moron non-hardware-guy understanding of SPI from Wikipedia, it's basically just a continuous bitstream -- you drive SS low, you start SCLK, and then data is latched on MISO and MOSI, one bit each direction per tick of SCLK.
Now, the current NETMF abstraction for SPI provides several functions. In my case, I'm transmitting a byte, and then I want to receive a byte in return from my SPI slave device. So I do:
var statusBuffer = new byte[2]; statusBuffer[0] = 0xD7; spi.WriteRead(statusBuffer, statusBuffer);
In the failure case, we are seeing MISO stuck at 0xFF. That is, statusBuffer[1] always equals 0xFF. It's supposed to be something different (specifically 0x8C).
So maybe if I understand more about "variable-bit SPI" it will help me diagnose this. I note from the provided ExtendedSpiConfiguration that the default value for BitsPerTransfer is 16. I am currently using a a regular SPI.Configuration, so I presume that I'm using 16 as BitsPerTransfer (the default).
So is a "transfer" defined as "the time between driving SS low and driving SS high"? If it is, then I may have some serious problems, because my transfers vary in length. I send various commands to the SPI slave device, and some commands are basically just the command byte, with a one byte response. Some commands have more structure (a command byte, three address bytes, 264 bytes of data), etc. So some transactions are one byte + one byte response, some transactions are 268 bytes + no response.
FYI, the device I'm talking to is a Xilinx XC3S50AN and the SPI documentation is here. The 0xD7 command is "Status Register Read". But I'm not sure understanding this is really needed.
My SPI code works fine on a Netduino Plus with older firmware and the 48KB RAM setup:
SolutionReleaseInfo.solutionVendorInfo: Netduino Plus (v4.1.0.5 b2) by Secret Labs LLC