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
SPI bug report (NETMF bug)
Started by
Mike P
, Sep 08 2011 11:40 AM
2 replies to this topic
#1
Posted 08 September 2011 - 11:40 AM
- Mario Vernari likes this
#2
Posted 08 September 2011 - 12:20 PM
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
Biggest fault of Netduino? It runs by electricity.
#3
Posted 09 September 2011 - 08:08 AM
I have posted a comment about the previous issue about the slowness of the SPI.
http://netmf.codeple...m/workitem/1111
http://netmf.codeple...m/workitem/1111
Biggest fault of Netduino? It runs by electricity.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users