2 replies to this topic

[Mike P]

Hi I think this is a bug in the netMF code. Would any of you code gurus like to have look and tell me if you agree?
Feel free to visit codeplex and vote.
http://netmf.codeple...m/workitem/1219

AT91_SPI_Driver::Xaction_Stop() has CS release sequence reversed

After the SPI transaction completes the Chip Select should be released before setting MOSI, MISO and SCLK to their idle levels.
in 4.1 and 4.2RC2 the MOSI and SCLK pins are both set low before CS is deactivated.
I am not sure but perhaps SCLK should be set low or high to honour the Clock_IdleState setting.
The file is C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_SPI\AT91__SPI.cpp
Lines 376-384 should be moved up to line 342
This would only cause a problem for slaves where the Clock_IdleState was true. In this instance an unwanted clock edge is sent before chip select is released. Depending on how the slave has been implemented this may have no effect.

Here is a capture of the SPI transfer and you can see MOSI and SCLK being set low before CS is released.traces are SCLK, MOSI, MISO, CS.
 single sample.png   4.94KB   19 downloads

[Mario Vernari]

You are right. To tell the truth, I wonder why they set both the MOSI and the SCLK as output low, instead of leaving them as are. The problem has not figured out before, because both the HC595 and the HC165 shift on the rising edge. BTW, the problem on slaves are not the IdleState, but when they shift on falling edge. The IdleState is minimally involved (i.e. you may set IdleState=true for the HC595, but it has no side-effect because it shifts on rising edges). I checked the firmware 4.1 and it is the same thing. Thanks Cheers

[Mario Vernari]

I have posted a comment about the previous issue about the slowness of the SPI.
http://netmf.codeple...m/workitem/1111