cancel
Showing results for 
Search instead for 
Did you mean: 

SPI problem with hardware NSS management

mudrovc
Associate II
Posted on October 26, 2009 at 04:22

SPI problem with hardware NSS management

#stm32f0 #metoo-maybe #nss #dma #spi
53 REPLIES 53
slawcus
Associate II
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 ]

mudrovc
Associate II
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
Posted on May 17, 2011 at 12:38

True, I just observed signals on the scope and NSS is always zero.

mudrovc
Associate II
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 ]

roger7
Associate II
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?

slawcus
Associate II
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 ]

mudrovc
Associate II
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 ]

mudrovc
Associate II
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. :-?

headbanger_m3
Associate
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

16-32micros
Associate III
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.