2009-10-25 08:22 PM
SPI problem with hardware NSS management
#stm32f0 #metoo-maybe #nss #dma #spi2011-05-17 03:38 AM
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 ]2011-05-17 03:38 AM
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.2011-05-17 03:38 AM
True, I just observed signals on the scope and NSS is always zero.
2011-05-17 03:38 AM
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 ]2011-05-17 03:38 AM
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?2011-05-17 03:38 AM
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 ]2011-05-17 03:38 AM
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 ]2011-05-17 03:38 AM
2011-05-17 03:38 AM
2011-05-17 03:38 AM
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.