SPI problem with hardware NSS management

[mudrovc]

Posted on October 26, 2009 at 04:22

SPI problem with hardware NSS management

#stm32f0 #metoo-maybe #nss #dma #spi

[oli2]

Posted on July 22, 2012 at 17:44

Another vote here, just run into this issue. Can't quite believe automatic SS control is not implemented, and the reference manual is completely unclear.  

ST need to at the very least least respond with some information here... Is it a bug? Is it a ''feature''? Will it be fixed? When?

[bart239955_st]

Posted on January 22, 2013 at 11:34

We meanwhile are already beginning 2013. - What’s the current status of this issue?

I’m using the SPI bus on a STM32F2xx and looking at the SPI-CS pin on my scope, I seem to have the same problems.It would be nice to know what exact is the expected behaviour of this chip-select pin.(Intended behaviour or a bug whatever)

[Amel NASRI]

Posted on January 29, 2013 at 16:40 Hello, This discussion was started since 2009 and it still alive, or may be the problem still there with SPI. I think it should be better to re-descibe exactly the problem in a new thread. I guess it will be hard to limit the exact scope throw this long discussion. ST.MCU

[Tesla DeLorean]

Posted on January 29, 2013 at 17:48

I think the problem here is a recurring one, that the hardware driven NSS doesn't function in a usable way for a lot of SPI applications. A lot of people will reasonably expect the chip select pin to assert/unassert in a periodic fashion, perhaps at every byte/word boundary or burst transaction.

From the reference manual RM0090– NSS output enabled (SSM = 0, SSOE = 1) This configuration is used only when the device operates in master mode. The NSS signal is driven low when the master starts the communication and is kept low until the SPI is disabled. The last part of the sentence is the most problematic, disabled how exactly? The DMA running out, the register underflowing, physically disabling the peripheral? What/how exactly? Perhaps some examples of some common SPI parts (EEPROM, Accelerometer, SD Card), where the hardware NSS control is demonstrated effectively.

[hanzouti_iia]

Posted on February 02, 2013 at 08:06

Hello,

I think there is no problem concerning the hardware NSS management, you have just to add a pull up by hardware or Software in the NSS line, and then every thing works correctly.

[Tesla DeLorean]

Posted on February 02, 2013 at 11:37

I think there is no problem concerning the hardware NSS management...

Really? The hardware needs to modulate the NSS pin in a manner suitable for the attached peripheral, adjusting the pin directly in software does NOT constitute a hardware control/management solution.

[Amel NASRI]

Posted on February 27, 2013 at 12:12

There is no issue with NSS management...NSS hardware toggling available...

Yes, there is no issue with NSS behavior for F1, F2 and F4 MCUs.

Before explaining how, I want to inform you that the behavior you are expecting is available with F0 and F3 families.

Now to explain the current behavior for F1, F2 and F4:

NSS pin is driven low by the master to inform that all the other connected SPIs are potentially slave. This signal remains active and forced by the master until the master is becoming slave or is disactivated (switched-off, SPE=0 in SPI_CR register).

It means if a master sends a data and stops for a moment before sending another data, NSS pin will stay low.

The utility of the NSS hardware mode depends on the use case: -

Point to point SPI communication: NSS OUTPUT pin is not mandatory to be used for a master. This feature is a way for a master to control its slave forcing NSS pin low as soon as it is the master of the communication.

-

Multi-Slave mode: There is one master and more than two slaves. In this case, there is no need to use NSS HW mode, since for each slave you need a dedicated GPIO to select it.

-

When there are more than two SPIs connected on the bus, and more than one could function as Master. It is NEEDED to use NSS HW output to know who the master is at the beginning of the session. In this case the other master(s) should manage that the NSS line could go low and in this case behave as slave(s) or stay inactive. Here the NSS HW output is NEEDED to know each time who is the master. In this case, all the NSS pins of all SPIs should be connected together. When an SPI wants to broadcast a message, it has to pull NSS down to inform all others that there is now a master for the bus. 

I hope this post will clarify the NSS Hardware management feature.

So, for the ones who want it, you can switch to F3 or F0 and check the NSS hardware toggling feature.

Best Regards,

ST.MCU

[v239955_st]

Posted on February 27, 2013 at 15:09

Hello,

I managed to get NSS working with DMAon a STM32F0 MCU, and have

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/28510/spitransfer.zip

needed to accomplish that. The very, very weird thing I encounter is that the NSS pulse is going high 30ms AFTER the SPI1 has been disabled in the DMA routine. You can take a look at the code, I lower pin C8 after disabling the SPI (which happens 4.7µs after the last CLK flank), but it takes another 38 ms before the NSS rises again! In the reference manual (RM0091) it is stated that the NSS will rise after the SPI is disabled, so where do I get this delay? View of data, and PC8 dropping after transmission, and after SPI1 is disabled. Transmission takes 235µs: View of complete transmission (on this scale only a white bar on CLOCK), with NSS pin going high ~38ms after the SPI1 is disabled. WHY? ST, please write a decent application note with examples of SPI and DMA usage, and verify the output. I previously worked with Atmel XMEGA, please take a look at their documentation as an example. Why is the NSS pin lagging so much? ________________ Attachments : spitransfer.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0w9&d=%2Fa%2F0X0000000bgK%2FVG2HiWVyYJ4ExjyUCZOuNeNTVcqA1.rLiUf3p2B_1LY&asPdf=false

[kaylee]

Posted on March 07, 2013 at 07:42

Hi,

I have been dealing with an SPI issue for a few weeks and can't seem to figure out what is wrong.  I think it steams from the NSS issue. How did you configure the control registers so that you could use the spi effectively (for transmit and receive) while using a different io pin for chip select.

[Tesla DeLorean]

Posted on March 07, 2013 at 16:17

Suggest you start a NEW thread, post your code, and your issue, and cite this thread if it is at all relevant to your usage of SPI chip select for your part.