SPI Master NSS always low in STM32F4

[Andres Cao]

Posted on March 03, 2017 at 12:34

Hi guys!

I'm configuring the Nucleo 64 with the STM32F446RE to use SPI as a Master.

The problem I'm having right now is that the NSS pin is always low. Clock and MOSI are perfect. What I would like is that the NSS is high, and goes low during the transmission, then high again.

I've tried setting the NSS as Hardware output, and Software in Cube, but still failed to get what I want. 

I think this configuration should be sorted with the following 3 bits, from CR1 and CR2. Right now Cube is setting SSOE= 1, SSM=1, SSI=1. And the NSS pin is configured as hardware output in Cube. 

Any clues on how should I setup this? I would like to avoid having to use a random pin as CS and pull it manually.

Thanks!!

[BCoch]

Yes, JW. (Actually I call LL_SPI_Disable.) If I set it again (by calling LL_SPI_Enable) after setting transfer direction to LL_SPI_HALF_DUPLEX_TX, NSS gets re-asserted, and left that way (even though there's no data to transmit).

[waclawek.jan]

> NSS gets re-asserted

That is 0, i.e. pulled to ground?

Interesting.

JW

[EDIT] Stupid me, this is the expected behaviour. I never used the "hardware" NSS as master (exactly because of its very limited utility), so I developed a misconception of how it works since this has been discussed here. Sorry.

[RSext]

The documentation for NSS is badly written and misleading.

When you enable the SSOE bit, NSS follows SPE. This is probably not what you (or anybody) wants. I haven't seen other parts that behave this way.. It's slower than managing NSS manually via GPIO.

For fully automatic operation of NSS, you need to enable NSSP. The docs in section 28.5.12 imply that this bit controls pulsing of NSS mid-frame, but it also control assertion of NSS before and after the frame, too.

[TA1]

Dear all

I have the exactly same problem. I am using STM32F745VET and I am trying to achieve SPI master Tx only communication with hardware NSS output control. I set up ST Cube, and also other setting in C file according to what user manual exactly explains. I spent many hours to try many other options according to my previous experience. I read SPI and DMA sections of the user manual two times but nothing solved.

I tried to enable internal pull up resistor of NSS pin and I can see small voltage change. If I use NSS mode it works perfectly. If I select TI SPI protocol, it also works. However, NSS cannot be controlled by hardware in Motorola SPI protocol. I set up exactly what user manual say and NSS never be high. When I enable SPI it stays low, whenever I disable it, it stays low with small difference then when it is enabled around ~0.2V. I though it is about multimaster mode features (there is only one master and one slave in my configuration and the microcontroller is master what I work on) and after finishes communication it turns the NSS output as NSS input then I added hardware a pull-up resistor and It still doesn't work. It is really strange because ST doesn't mention on their documentation. I looked Errata Sheet but it doesn't mention in there. I faced a problem in STM8S years ago and it was in Errata Sheet. I faced another problem just a week ago in DMA setting and ST accepted their mistake in Cube and they promise to fix next release. However, as far as I understood from the topic, they are silent about the issue. Only Imen DAHMEN responded but it is not satisfied answer.

Anyway, I decided to use soft NSS control and it worked but why hardware NSS control doesn't work? ST employee should clarify. I believe they are human like us and not superhero (what waclawek.jan say above) but at least they should clarify if it is caused by a hardware bug or our mistake. If it is our mistake, they should direct us to find our mistake.

I hope they will inform us.

Regards

[BCoch]

Hi TA,

Are you sure the NSS pin is configured in the appropriate special function mode?

Are you sure nothing else is driving that line?

The fact that you are seeing a small change with the internal and external pull up suggests to me that at least the SPI part of the chip is releasing the line, but that something else is still pulling it down.

For me (on an STM32G071) if the internal pull-up is enabled, the line rises slowly (due to the weak pull-up) once the SPI driver is disabled, but it does get to Vcc okay.

Another (less likely) possibility is that the SPI transaction isn't finishing for some reason, so even if you disable it, it's waiting for data or something before releasing the line. You might see if any error bits are set, right before disabling it.

Or, of course, it's simply a bug with the STM32F745VET...

I do think it's odd that it's driven in this open drain mode, and feel that it would be better if the chip would at least drive the line high at the end of a transaction before releasing it.

-- Bruce.

[TA1]

Dear Bruce

Thank you for your reply. Let me clarify your doubts:

Are you sure the NSS pin is configured in the appropriate special function mode?

Yes I am absolutely sure and on the other hand, I use the ST Cube Mx for the configurations. It does for me. However, I also checked manually.

Are you sure nothing else is driving that line?

%100 sure. The line is directly connected to a fiber optic receiver. Signal is not sharing with any other buses/chips/etc. I also mentioned in my previous post that if I set NSS pulse mode or TI mode, NSS output works well. So if the case what you are in doubt exists, it wouldn't work for those cases, would it?

The fact that you are seeing a small change with the internal and external pull up suggests to me that at least the SPI part of the chip is releasing the line, but that something else is still pulling it down.

Yes, it seems like that. However what it is. If the output doesn't work in NSS pulse mode or TI mode at all, I can think about short circuits on the card. The microcontroller package is small, maybe there would be short circuits with other pins which are neighbor pins of NSS. I checked all soldering two times with a microscope and nothing is there.

For me (on an STM32G071) if the internal pull-up is enabled, the line rises slowly (due to the weak pull-up) once the SPI driver is disabled, but it does get to Vcc okay.

This is perfect and what it should be. However I spent 2 days to solve it and I couldn't.

Another (less likely) possibility is that the SPI transaction isn't finishing for some reason, so even if you disable it, it's waiting for data or something before releasing the line. You might see if any error bits are set, right before disabling it.

No it is not true. I completely disable SPI, DMA Stream and also TXDAMEN bits. Nothing is there... Also, user manual says that NSS goes to low whenever SPI enable and it keeps low until SPI is disabled. So when I disable SPI, NSS should be high according to user manual. In NSS pulse mode, It works well. It start with high and it goes to low before first data is relased on the line. When the first half-word finishes, NSS become high for certain amount of time and it becomes low again before the second half-word. When all data transfer is completed, NSS goes high and stay as high...

Or, of course, it's simply a bug with the STM32F745VET...

Might be. If it is, ST should recognize and we shouldn't spend days to find the problem or if it is our mistake they should help us to find out the problem. We are all human and it might be by mistake. However I realize I am not alone... First post opens in 2017 and the subject is still open.

I do think it's odd that it's driven in this open drain mode, and feel that it would be better if the chip would at least drive the line high at the end of a transaction before releasing it.

Its behavior is like open drain. That's why I added pull up resistor but it didn't solved. I am using soft NSS.. before activate DMA stream, NSS pin is driven low, whenever FTVL and BSY flag becomes zero, I disable DMA stream, clear transmit complete flags, set NTDR register for next communication. Also NSS is driven high until next DMA stream will be enabled. It works like that but hardware NSS is very common features of all microcontrollers. It should work...

Thank you for your effort and time

Regards

[waclawek.jan]

> The line is directly connected to a fiber optic receiver.

Do you have any specification (datasheet etc.) for the input where do you connect NSS?

Can you disconnect it and measure the NSS output when disconnected from any load?

JW

[TA1]

Dear Jan

Of course I can share fiber transmitter product number and you can download the datasheet (AFBR-1624Z). However it would be time consuming. The hardware works very well in NSS pulse mode and also TI mode. So the problem should not be about hardware of my circuit. It would be hardware problem of microcontroller, wouldn't it. Because fiber transmitter input or the line doesn't know which mode is selected in microcontroller. On the other hand, same pin can control the same fiber transmitter in software NSS control. When I defined NSS pin as standart general purpose push-pull output, it can be high and low according to my order in the code. If I selected NSS pulse mode and NSS pin is set an alternate function, it works very well. Whenever I enable SPI it goes to low and it goes high between half-word for certain amount of time (maybe One or two clock cycle, I didn't meausure), and whenever I disable SPI it goes to high again with same fiber optic receiver. Similarly TI mode it works..

Thank you very much for your effort.

Regards,

[waclawek.jan]

In TI and NSS modes the NSS pin is actively pulled up between/after transmission, whereas in "normal"mode, if you disable SPI module, the pin goes threestate. The pullup is equivalent of 40kOhm, i.e. it can source maybe 0.1mA, whereas active push/pull output can source tens of mA, depending on particular circumstances. The DS for AFBR-1624Z says "Standard TTL compatible input", but at the same time also presents a value "Data Input Resistance R IN 2 kOhm".

I'd recommend to forget about hardware NSS, set the pin as GPIO Out, and control it in software.

JW

[TA1]

Dear Jan

I have already forgot it and I am controlling in software but why? This is the question. I have been developing electronic cards and embeded codes for 16 years and I have been used Microchip PIC Series, Cypress Psoc Series, Texas TMS320F Series and also ST STM8S. I used SPI many times and this is first time I faced a problem like that. I cannot imagine I am only to face the problem. It is clear from this topic I am not alone and why we try to solve the problem ourself. If it is hardware bug, ST should recoginize and others should not spend time to find a reason and a solution for it. If it is not hardware bug in mocrochip but if it is our mistake they should help us to find problem. I believe it is not my fault because NSS pulse mode or TI mode shoud be share same output topology with NSS hardware control in normal mode. It is working in NSS pulse mode and TI mode so it should work hardware control of NSS in normal mode.

Anyway I am tired in that subject and I control NSS pin in software. Yesterday I found another problem and I will write in a seperate topic for other developer. Most probably it is about hardware issue. I spent hole day to understand. I should write for other developer to save their time.

Thank you very much your effort

Regards