The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I've spent the last couple of days working with SPI and I've just moved some code from the N+ to the N+2 and I'm seeing some odd output from the SPI pins. So time to break out the LA and have a look at what's going on.
The code is:
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;
namespace NetduinoApplicationPlus2Test
{
public class Program
{
private static SPI spi = null;
private static SPI.Configuration config = null;
private const int BUFFER_LENGTH = 17;
public static void Main()
{
config = new SPI.Configuration(SPI_mod: SPI.SPI_module.SPI1, // Which SPI module to use?
ChipSelect_Port: Pins.GPIO_PIN_D10, // Chip select pin.
ChipSelect_ActiveState: false, // Chip select is low when SPI is active.
ChipSelect_SetupTime: 0,
ChipSelect_HoldTime: 0,
Clock_IdleState: false, // Clock is active low.
Clock_Edge: true, // Sample on the rising edge.
Clock_RateKHz: 500);
spi = new SPI(config);
byte[] transmitBuffer = new byte[BUFFER_LENGTH];
byte[] receiveBuffer = new byte[BUFFER_LENGTH];
for (byte index = 0; index < BUFFER_LENGTH; index++)
{
transmitBuffer[index] = index;
receiveBuffer[index] = 0;
}
while (true)
{
for (byte counter = 0; counter < 255; counter++)
{
string output = counter.ToString() + ": ";
transmitBuffer[0] = counter;
spi.WriteRead(transmitBuffer, receiveBuffer);
for (int index = 0; index < BUFFER_LENGTH; index++)
{
output += receiveBuffer[index].ToString() + " ";
receiveBuffer[index] = 0;
}
Debug.Print(output);
Thread.Sleep(2000);
}
}
}
}
}
On the N+ I see what I'm expecting, MOSI goes high and sometime later Enable goes low followed by the clock starting to run. The LA is able to interpret the data correctly.
On the N+2 I see what appears to be the clock starting to run before Enable has gone low. As a result the enable line falls whilst the clock signal is high. As a result the LA displays the message The initial state (idle) of the CLK line does not match the settings. It looks like the clock starts running ~3.8us before the Enable line falls. This code worked correctly on the N+ and the LA was able to interpret the data correctly.
Anyone able to suggest where I might be going wrong?
Just been following up on this and I have a couple of more observations:
I tried changing the CS pin from D10 to D9 in case there was a problem with the choice of pin. This gave me the same result.
Next change I made was to set the application to sample on the falling edge. I also changed the software configuration on the LA to match. Running the application allows the LA to process the data. More interesting was what happened to the traces.
In the initial post I mentioned that it looks like the CS line is dropped 3.8us after the clock starts running. If I sample on the falling edge it looks like the CS line is dropped 3.4us before the clock starts running.
Regards,
Mark
Edit: Modified the last paragraph to make the observations a little clearer.
Hi Mark,
Thank you very much for the details.
We will investigate this in the next few days, to see if it's operating by design or if there's something we should tweak in the firmware for the second scenario.
Chris
What happens if you use a non-zero value in the setup and/or hold times?
There might be an issue when the setup time is zero (that was not present on the N+1).
ChipSelect_SetupTime
The setup time for the chip select port. In other words, this parameter specifies the amount of time that will elapse between the time at which the device is selected and the time at which the clock and the clock data transmission will start.
ChipSelect_HoldTime
The hold time for the chip select port. In other words, this parameter specifies the amount of time that the chip select port must remain in the active state before the device is unselected, or the amount of time that the chip select will remain in the active state after the data read/write transaction has been completed.
We will investigate this in the next few days, to see if it's operating by design or if there's something we should tweak in the firmware for the second scenario.
There is indeed something strange going with SPI+NETMF+STM32 in specific configurations. We're working on a firmware update now, and are will try to tweak the core NETMF code a bit to bend it to our will
There is indeed something strange going with SPI+NETMF+STM32 in specific configurations. We're working on a firmware update now, and are will try to tweak the core NETMF code a bit to bend it to our will
Thanks for the update. Look forward to seeing the fix released. Let me know if you need someone to test prior to release.
I'm also willing to test. In my case I'm running 4.2.1.2 firmware (which fixed my I2C problem) and observe that SPI is not working regardless of frequency.
I took some photos of the SPI output on my logic analyzer (pin 6 is CS for the slave) for both Netduino Plus 2 and Netduino Plus. Hope this helps. Note that the NP was running @ 4 MHz and the NP2 @ 1 MHz. The NP2 doesn't make it as far in the initialization routine.
Netduino Plus @ 5 uSec
https://docs.google....aElmZzc0dHZxUzA
Netduino Plus @ 2 uSec
https://docs.google....NVFNNmMxS3drTm8
Netduino Plus @ 1 uSec
https://docs.google....QWVXUk4xRC1vRkU
Netduino Plus 2 @ 10 uSec (SPI may be running @ 1 MHz)
https://docs.google....ZFpRYkYzRTJRSm8
I took some photos of the SPI output on my logic analyzer (pin 6 is CS for the slave) for both Netduino Plus 2 and Netduino Plus. Hope this helps. Note that the NP was running @ 4 MHz and the NP2 @ 1 MHz. The NP2 doesn't make it as far in the initialization routine.
You may want to try changing the clock frequency for the SPI interface. I solved my problem by merely changing the clock frequency from 1000 KHz to 1250 KHz. I found It worked at 4000 KHz down to about 1150 KHz. E.g.:
SPI_CS_CONFIG = new SPI.Configuration(MP3_XCS_PIN, false, 0, 0, false, true, 1000, SPI.SPI_module.SPI1); // fails 9 of 10 trials
SPI_CS_CONFIG = new SPI.Configuration(MP3_XCS_PIN, false, 0, 0, false, true, 1250, SPI.SPI_module.SPI1); // works 10/10 trials
You may want to try changing the clock frequency for the SPI interface. I solved my problem by merely changing the clock frequency from 1000 KHz to 1250 KHz. I found It worked at 4000 KHz down to about 1150 KHz.
Interesting that you managed to get this working at 1250 KHz as mine did not start to work correctly until I reached 1400 KHz. At least I'm back working again.
Sorry to post to such old topic, but since I am researching using SPI right now, for completeness of this thread I wanted to mention that according to Chris Walker's post on 4.2.2.2 this appears to be resolved:
