SPI problem with hardware NSS management

mudrovc · ‎2009-10-25

Posted on October 26, 2009 at 04:22

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

gdp123a · ‎2011-05-17

Posted on May 17, 2011 at 12:38

Thank you i.koniya for reminding me about this issue - I had repressed it completely.

Every design I have planned for the STM32 would benefit from automatic CS generation. The 16-bit data frame option has saved me a lot time - a great feature. But having to manually control the CS line has been a nuisance.

JJ - your idea of a thread for user's ''top three STM32 suggestions'' sounds great, but I think ''top five STM32 suggestions'' might be better. I will start preparing my list.

Greg.

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 12:38

Hi jj, Greg,

I Like you idea 🙂 I will fully support you on this . Please start the Polls and will I be engaged to maintain this Thread in a proper way with some Edits and Format shaping if required .

Cheers,

STOne-32.

mudrovc · ‎2011-05-17

Posted on May 17, 2011 at 12:38

Hello STOne-32, hello all.

Is there some news about ''automatic NSS-CS pin management''? Actually I'm working with a ''new'' STM32F103VE6 and I still have the same behavior. The NSS pin is not toggled automatically by the hardware during master SPI transfer. It just stays low, it's impossible to use it for -CS slave driving.

But, seems for the ST engineers this is not a bug in the silicon. Which is strange, because I have some experience with STR9 micros from ST. On this micro, the NSS pin works normally - it goes low/high automatically in master mode. So it can be connected to the -CS slave pin. I believe that the peripherals are almost the same for STR9/STM32, but seems it's not the case for SPI.

Anyway, if this is not a silicon bug, please correct the manual, because inside it - the information is not correct. Or it's not clearly written. Just write - ''The NSS pin cannot be driven automatically by the hardware'' :-?

[ This message was edited by: mudrovc on 30-03-2009 18:05 ]

dmatheis · ‎2011-05-17

Posted on May 17, 2011 at 12:38

Hello,

Is there any news with this issue? At this point the only way to manage a CS is via GPIO_SetBits(...)/GPIO_ResetBits(...) manualy?

As soon as I'll set the NSS-Pin as AF-Pin it switches off and not when I'll configure the SPI-Interface, as it is here mentioned...

[ This message was edited by: dmatheis on 08-07-2009 14:40 ]

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:38

This request was among an organized listing submitted here to ST-One-32 - now seven months old.

Press is on for new devices - forum resources have clearly been ramped down - many here are forced to conclude that ''when/if'' the ''lead clients'' stumble upon this/other STM32 weaknesses - first discovered/documented HERE - only then will maker attempt to correct...

My firm/clients have serious reservations about seeming ''rush'' to new introductions - which may repeat weaknesses/inefficiencies dutifully reported here - and (forgive me) appear to languish.

redmonds · ‎2011-05-17

Posted on May 17, 2011 at 12:38

I've just hit this NSS problem.

What is good:

That the discussion is here on the forum to stop me spending hours trying to work out what I have done wrong. Thanks guys!

What is not good:

That NSS doesn't behave as expected.

What I expected to happen:

I'm expecting to see on my scope what I see in Figure 208 of RM008 Reference Manual, i.e. NSS goes high after the transfer.

Why a working NSS would be very helpful:

I'm using the SPI (with DMA) to clock data into shift registers. If NSS went high after the transfer (as indicated by Figure 208), I could use that edge as the strobe to latch the data across into the shift register outputs. Everything would be done by the peripheral. Fire and forget. As it is with the broken NSS, I have to generate an interrupt and use that to strobe the gpio output (I hate controlling gpio from within interrupt routines).

Any update as to when this will be fixed?

janvi · ‎2011-05-17

Posted on May 17, 2011 at 12:38

Anything news to the NSS problem ???

http://www.st.com/mcu/forums-cat-9006-23.html

it costs me a complete weekend to connect a LTC1661 DAC with CS!/Load to 48pin STM32.

Depending from clock setup, there may a reasonable delay between TXE bit indicates empty data buffer and the last bit shiftet out to MOSI. This way, a software generated LH Edge of NSS sometimes may cut the last bit. Poll BSY instead of TXE works but adds over 1uSec delay.

[ This message was edited by: Janvi on 25-10-2009 21:49 ]

domen2 · ‎2011-05-17

Posted on May 17, 2011 at 12:38

Janvi,

I think this might be similar to a problem I once had. Try polling RXNE. (If data is received it's definitely sent on the wire too, right?)

tecnico23 · ‎2012-04-24

Posted on April 24, 2012 at 15:40

Hello everybody,

A year after the last post, I would like to know if the problem with hardware NSS management has been solved.

Regards,

A. Paiva

davef967 · ‎2012-06-07

Posted on June 07, 2012 at 21:27

Hi,

I am also interested in the answer to this issue. I just ran across it with a quad DAC where the data for each channel must be framed. It appears that using the DMA for this function is completely useless. Bit banging the framing pin is ridiculous and using an interrupt after each transfer isn't any better.

ST: can you help or at least respond with something?

DaveF967