7 replies to this topic

[Blake Ramsdell]

I'm having some trouble with a 4.1.1.0 a5 Netduino Plus using SPI (MISO data is always 0xFF), and maybe it will help if I understand more about "variable-bit SPI" and the changes in the SPI area.

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

[Ward]

I think the 0xFF is because the SPI interface is now defaulting to 15(?!) bits per transaction, and the Xilinx flash is misinterpreting the instruction as a result. Looking at my 'scope, I see 15 clock rising edges, and the 0x8C is right justified (i.e. 0x008C). If the flash is expecting an 8-bit command, it's likely looking at the first 8 bits it receives and seeing 0x01 (the 8 MSBs of 0x008C), which is an undefined command. Instantiating an ExtendedSpiConfig instead, with "8" as the "BitsPerTransfer" argument, doesn't appear to affect anything...I'm still seeing 15 clock edges.

[Chris Walker]

Blake, Ward: that's a bug in alpha 5 which has been fixed for alpha 6. [Somehow we wrote "| 0xFF" instead of "& 0xFF" when calculating bits.] Chris

[Ward]

Sweet, thanks Chris! Looking forward to alpha 6.

[Blake Ramsdell]

Thanks for all of the followup, and I understand that there are some changes in alpha 6 that should help. I would be interested to hear some more about the rationale for the change. That is, I presume that this field was added to handle a particular SPI use case. What is it? Is there some environment that takes a stream of bytes, but those bytes are padded with leading / trailing zeroes up to some field length? Certainly if there is another forum post about this, I'd appreciate a pointer and I'll go read it and comment there as appropriate. I guess as long as the default value in the final release keeps all of the existing SPI code working, I don't care. But something smells wrong here.

[Chris Walker]

Thanks for all of the followup, and I understand that there are some changes in alpha 6 that should help.

I would be interested to hear some more about the rationale for the change. That is, I presume that this field was added to handle a particular SPI use case. What is it? Is there some environment that takes a stream of bytes, but those bytes are padded with leading / trailing zeroes up to some field length? Certainly if there is another forum post about this, I'd appreciate a pointer and I'll go read it and comment there as appropriate.

I guess as long as the default value in the final release keeps all of the existing SPI code working, I don't care. But something smells wrong here.

Hi Blake,

Most serial devices are 8 bits, no parity and 1 stop bit. But there are the odd ones that still need to work (1.5/2 stop bits, even parity, etc.)

The same thing happens with SPI. Most devices use 8-bit transfer (or 16-bit), but there are some that need 9-bit transfers. Or 11-bit. This seems to happen most frequently in SPI-based graphical displays.

The Atmel chip supports variable-bit SPI, but .NET MF only supports 8-bit and 16-bit by default. So we're extended the platform to support the whole range. We've extended it in a way that won't break existing code compatibility...but somehow flipped a bit in the latest alpha when adding some "range protection".

Chris

[Blake Ramsdell]

The same thing happens with SPI. Most devices use 8-bit transfer (or 16-bit), but there are some that need 9-bit transfers. Or 11-bit. This seems to happen most frequently in SPI-based graphical displays.

OK, thanks Chris -- I have Xilinx SPI myopia and that's all 8-bit. Thanks for all the followup.

[CW2]

I would be interested to hear some more about the rationale for the change. That is, I presume that this field was added to handle a particular SPI use case. What is it?

I think the original request was to support 9-bit SPI for Nokia 6100 Color LCD controller.