I have firmware 4.2.2.2 on brand new Netduino Plus 2 boards. The SPI clock line stays high during idle times. I have tried changing the parameter to tell it to stay low, but it has no effect. Any suggestions?
Thanks - Frank
  | ||||||||||||||
SPI Clock stays High during Idle
Started by k0fei, Dec 31 2013 06:32 PM
9 replies to this topic
#1Posted 31 December 2013 - 07:06 PM I have firmware 4.2.2.2 on brand new Netduino Plus 2 boards. The SPI clock line stays high during idle times. I have tried changing the parameter to tell it to stay low, but it has no effect. Any suggestions?
Thanks - Frank
#2Posted 31 December 2013 - 11:33 PM
Hi Frank,
When you say idle times...do you mean between SPI transactions (when SPI_CS is not selected) or between bytes (while SPI_CS is selected)?
The way that SPI is built in NETMF, the concept of "clock idle state" only exists while a device is selected--and then that idle state changes as you move between different devices (and their specific SPI configurations). The SPI data pins are reserved during a SPI transaction (although some SPI pins can be reserved more permanently, depending on if the SPI configuration was passed into the SPI class when the SPI object was constructed--or assigned to the Config property later).
Are you only talking to one device without using SPI_SS--or only using one clock idle state configuration in your project and have devices that need clock idle to remain consistent permanently? If so, we can look at potential improvements to the way that NETMF handles SPI_CLK between transactions in a future firmware update.
Chris
#3Posted 01 January 2014 - 02:41 AM Thanks Chris. I am talking to 8 devices, but doing my own select before starting a transfer and strobing in the data after the transfer. After a transfer I would like to clock to go low and stay low between transfers. I suppose I could put an inverter in the hardware, but hoped there was a way to do it in software.
By the say, how do you debug the firmware. I would be willing to give it a go, especially to fix the I2C driver. Emulating the I2C bus in software is not ideal.
Frank #4Posted 01 January 2014 - 02:41 AM http://forums.netduino.com/index.php?/topic/9685-firmare-4222-spi-mode-1-bug/ I had the same problem, but no answer.
#5Posted 01 January 2014 - 02:58 AM
baxter--ooh, logic analyzer capture! Thank you! I hadn't seen your post before, but this gives us the info we need to take care of that issue for you.
k0fei--while we're fixing the clock idle issue in the 4.3 firmware codebase, I'm also going to look and see if we can freeze the clock idle state when ending the SPI transaction. That would effectively do what you're looking to do--and you could still create an OutputPort at any point if you wanted to change the output state. [We may need to do this via input mode with respective pull-up/pull-down resistor, as I'm not sure we want to drive the pin permanently high/low even after the SPI class instance is garbage collected.]
Chris
#6Posted 01 January 2014 - 03:00 AM
Hi Frank,
What bug in the I2C driver are you wanting to fix? I don't have any I2C bugs on our fix list--and would like to make sure we address any issues you may have experienced there. To debug the firmware, you'll need to solder a MiniJTAG onto your Netduino and compile the firmware in debug mode. It's a whole lot of C and C++ code, but if you're adventurous it is open source and there for you to hack Chris #7Posted 31 December 2013 - 06:32 PM Hi Chris,
I left more info on the thread about the I2C not working including the test code.
I can get you a logic trace of the I2C bug but it just two lines staying high.
MiniJTAG - Got it. #8Posted 11 January 2014 - 05:56 PM I found some other problems related to the SPI.
In brief, I was trying a SPI data exchange (mode 0) with a slave device, but I wasn't able to make it working correctly. After "multi-checking" wiring and timing on the scope, my the latest clue was about the SS release. In practice, the trailing part of the message should terminate with SCK low, then the rising of the SS (being active low). The problem is that the SS rose a fraction of microsecond *before* the SCK, which is released earlier and, due an external pullup, generates a spurious edge. As stated, the data exchange was mostly working, however the device shown some strange behavior. The above issue has been experimented with the Netduino Plus 2, firmware 4.2.1.2. Here is the SPI config used:
SPI.Configuration config = new SPI.Configuration( SPI_mod: SPI.SPI_module.SPI1, ChipSelect_Port: Pins.GPIO_PIN_D10, ChipSelect_ActiveState: false, ChipSelect_SetupTime: 0, ChipSelect_HoldTime: 0, Clock_IdleState: false, Clock_Edge: true, Clock_RateKHz: 5000 ); So i decided to upgrade the board to the latest firmware 4.2.2.2 update 2. Unfortunately, the above glitch is still present, but the update generated another issue. At this point, the device isn't working any more. First off, it seems that the clocks aren't actually in sync with the MISO, specifically. Once the transaction begins, the clocks and MOSI are issued (probably) correctly, but the latter byte issued on the MISO is read shifted left as just one bit in the code. The device outputs 0x7C on the MISO, but the C# code returns 0xF8.
Another issue is related to the speed of the SPI. As stated, I was looking at the trailing part of the transaction. The first attempt was performed with the same configuration as above shown, then I tried to slow down the clock to 1000 (1MHz). The SCK line behaves differently upon its frequency.
I will attach some screenshots of the various cases. Due the limitation of my scope I really cannot do better, but I think should give the idea of the problem. Also pretty easy to reproduce.
SCK = 1 MHz (1000)
SCK = 5 MHz (5000)
SCK = 10 MHz (10000, just for comparison)
NOTE: on any screen the plots are (from top to bottom): SS, MISO, SCK, MOSI
Biggest fault of Netduino? It runs by electricity.
#9Posted 12 January 2014 - 05:37 AM Additional info. I rolled back the firmware to the 4.2.1.2, which runs pretty fine except for the "late" SS issue. However, the 0x7C issue by the slave is now read correctly, as expected. As a *temporary* workaround, I moved the two pull-ups (SCK and MOSI) as pull-downs. That prevents the extra-clock edge.
I'd add that the issues on "bit-lost" happen also in the leading part of a transaction, when the clock speed is pretty low. That is, everything seems going fine when I use 5000 as clock rate, but using 1000 or less the leading bits looks scrambled (and the transaction fails).
Waiting for a resolution.
Biggest fault of Netduino? It runs by electricity.
#10Posted 25 February 2014 - 04:38 AM
Hi Mario, k0fei:
This bug has been fixed in the new Netduino 4.3.1 firmware.
http://forums.netdui...-firmware-v431/
It turns out that the STM32 is very particular about the order of disabling SPI and configuring SPI pins. If we un-setup the pins in the reverse order of how we set up the pins, the SPI clock seems to be getting half a bit off for the first bit of the next transaction. We have altered the order of setup and tear-down and tested all 4 SPI modes.
Please let me know if everything is working now (or not working) for you.
Chris
0 user(s) are reading this topic0 members, 0 guests, 0 anonymous users | ||||||||||||||
|
||||||||||||||
This webpage is licensed under a Creative Commons Attribution-ShareAlike License. | ||||||||||||||