Netduino home hardware projects downloads community

Jump to content


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.
Photo

SPI Clock stays High during Idle


  • Please log in to reply
9 replies to this topic

#1 k0fei

k0fei

    Member

  • Members
  • PipPip
  • 10 posts

Posted 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

 



#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 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

#3 k0fei

k0fei

    Member

  • Members
  • PipPip
  • 10 posts

Posted 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



#4 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 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.

 

 



#5 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 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

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 January 2014 - 03:00 AM

Hi Frank,

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.

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

#7 k0fei

k0fei

    Member

  • Members
  • PipPip
  • 10 posts

Posted 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.



#8 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 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)

http://sdrv.ms/1j1pYON

http://sdrv.ms/1lQVleN

http://sdrv.ms/1j1qcW0

 

 

SCK = 5 MHz (5000)

http://sdrv.ms/1j1qegu

http://sdrv.ms/1j1qc8w

 

 

SCK = 10 MHz (10000, just for comparison)

http://sdrv.ms/1gxg971

http://sdrv.ms/1gxgd6H

 

 

NOTE: on any screen the plots are (from top to bottom): SS, MISO, SCK, MOSI


Biggest fault of Netduino? It runs by electricity.

#9 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 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.

#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 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 topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.