Skip to main content
mudrovc
Associate II
October 26, 2009
Question

SPI problem with hardware NSS management

  • October 26, 2009
  • 53 replies
  • 10394 views
Posted on October 26, 2009 at 04:22

SPI problem with hardware NSS management

#stm32f0 #metoo-maybe #nss #dma #spi
This topic has been closed for replies.

53 replies

mudrovc
mudrovcAuthor
Associate II
May 17, 2011
Posted on May 17, 2011 at 12:38

Hello All.

@jj.sprague

The SSM/SSI bits manages the NSS pin by the software. In my experiments - they works fine. I can manage the NSS pin like a normal GPIO, also. But to make some sort of DMA automation, it's better if the NSS pin can be managed by ''itself'' - i.e. hardware management :) For the moment I'm working with the software solution, but this consumes me a CPU time, so it's better to know - is it possible to drive it by the hardware.

@slawcus

About the SPI example 4 - I made a compilation for my target board. It didn't works for me - the NSS pin stays at zero, regardless of the SPI transfers. The overall example still works, of course, since the NSS pin is always in active state.

I'm still not sure that is a problem of the STM32 chip, or a problem introduced by me in some way. I'm using a code imported from an older STR9 project which has a similar SPI periferial. So I was surprised that it doesn't work on the smaller STM32.

slawcus
Associate II
May 17, 2011
Posted on May 17, 2011 at 12:38

One interesting thing that is not related to NSS.

Anyway, while testing NSS functionality I noticed that I forgot to change PLL values from 8 * 9 = 72 used in original example(this comes with in Rowley) to 12 * 6 = 72. I use 12 MHz.

/* PLLCLK = 8MHz * 9 = 72 MHz */

RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_9);

Hm... everything worked. Now, I changed PLLMul to 6 and SPI clock was changed for same factor (1.5) So STM was running at 108MHz instead of 72? :o

[ This message was edited by: slawcus on 03-07-2008 11:19 ]

slawcus
Associate II
May 17, 2011
Posted on May 17, 2011 at 12:38

Well... I'd like to hear from ST if they can provide working example with hardwire NSS (acting as output and changing states with each transaction).

P.S.

I put 6.8k pull-up to NSS line. Until SPI_Cmd(SPI2, ENABLE); NSS stays high, then it goes low and stays there. But if I add SPI_Cmd(SPI2, DISABLE); after the transaction it will go up again.

[ This message was edited by: slawcus on 03-07-2008 12:30 ]

roger7
Visitor II
May 17, 2011
Posted on May 17, 2011 at 12:38

I put 6.8k pull-up to NSS line. Until SPI_Cmd(SPI2, ENABLE); NSS stays high, then it goes low and stays there. But if I add SPI_Cmd(SPI2, DISABLE); after the transaction it will go up again.

I confirm that this is how Rev B. silicon behaved in my January 2008 tests. Frustrated from this ''feature'' I substituted NSS with SW control and went on. It ''smells'' like a bug, but if one looks at the datasheet SPI timing, there is no setup and hold times for CS w/ respect to CLK. Only marketing info shows how it works.

STR9 prefetch buffer story all over?

mudrovc
mudrovcAuthor
Associate II
May 17, 2011
Posted on May 17, 2011 at 12:38

So now it starts to look like a hardware bug in the STM32 chip?

[ This message was edited by: mudrovc on 03-07-2008 11:50 ]

[ This message was edited by: mudrovc on 03-07-2008 11:51 ]

mudrovc
mudrovcAuthor
Associate II
May 17, 2011
Posted on May 17, 2011 at 12:38

STOne-32, can you go in contact with ST engineers to check this issue?

P.S. Sorry that I'm pushing the message in front, but I really have a problem with my project timing. :-?

mudrovc
mudrovcAuthor
Associate II
May 17, 2011
Posted on May 17, 2011 at 12:38

Seems like, yes.

Till this moment we don't have a comment from ST guys.

[ This message was edited by: mudrovc on 09-07-2008 17:32 ]

[ This message was edited by: mudrovc on 09-07-2008 17:33 ]

ericbrocke9
Associate
May 17, 2011
Posted on May 17, 2011 at 12:38

Sorry guys but you should better read the manual as pointed out by STOne-32!

The manual (RM0008 rev 5) says on page 541:

''NSS output is enabled: when the STM32F10xxx is operating as a Master and the NSS output is enabled through the SSOE bit in the SPI_CR2 register, the NSS pin is driven low and all the NSS pins of devices connected to the Master NSS pin see a low level and become slaves when they are configured in NSS hardware mode.''

The NSS pin is mentioned as a select pin to activate the interface in slave mode (yes! NSS -> Not Slave Select. Surprised?).

Eric

p.s. The normal situation is a single master with multiple slaves which then requires a NSS line for each slave. The master has to select a specific slave which cannot done by one NSS pin.

[ This message was edited by: eric.brocke on 06-08-2008 21:10 ]

16-32micros
Associate III
May 17, 2011
Posted on May 17, 2011 at 12:38

Hi,

As stated by Headbanger you could check Our errata : section ''alternate function'' if you have conflicts when I2C2 or USART3 are enabled in this case?

Additional description of NSS pin management can be found in RM0008 rev5 page 541. Thx.

STOne-32.

headbanger_m3
Visitor II
May 17, 2011
Posted on May 17, 2011 at 12:38

Hi Mudrovc,

silly question, but did you had a look already at the latest Errata Sheet dated of July?

There seems to be some known limitations on serial interfaces when alternate/remap share some pins (section 2.4). The NSS signals pops up a couple of time.

A good contact of mine working at ST gave me that hint, when I asked him on known SPI_NSS issue? But he couldn´t confirm 100% this could be the reason, as he hadn´t all the elements of the issue.

Good luck mate!

Headbanger