Not getting clean reset

[gds2]

Posted on December 02, 2009 at 09:51

Not getting clean reset

[gds2]

Posted on May 17, 2011 at 13:26

When our board powers down and cools a bit (maybe 5-10 minutes off) on power-up it hangs on the first SPI transmission waiting for TX buffer to become empty, which it never does. After a bit of time to warm up (again maybe 5-10 minutes) it powers on properly and gets past the first SPI send and works OK after that. It can be powered off (for a short time) and back on successively after this and works fine.

If a software reset is done or if a jtag reset occurs using a debugger it resets and works OK, getting past the point where the first SPI transmission occurs. Hardware engineers have looked and see a proper reset signal on NRST at power on. When hung the debugger indicates a proper reset since the power on and NSRT pin reset reason bits are set in RCC_CSR register. However, when hung like this, an additional system reset seems to be needed to get it going. This 2nd jtag or software reset causes it to run properly. Again, see no problem at all if the board has run a while and warmed up, it seems. Any ideas?

[16-32micros]

Posted on May 17, 2011 at 13:27

Hi,

This seems you have some floating inputs that changes their states when temperature is varying, Check your GPIO configuration of the SPI peripheral. Hope this helps you, Cheers, STOne-32/

[gds2]

Posted on May 17, 2011 at 13:27

Right now the only input pin that is SPI related that I am not using is NSS. I am using the SPI1 port only as a master going to several slaves and using other ports at chip selects. You are right, the NSS pin to the SPI1 port is just floating. How should I configure the NSS pin to correctly support this?

Do I set NSS as an output and possibly configure the SPI_CR2 bit SSOE to 1? Thanks, -gds

[gds2]

Posted on May 17, 2011 at 13:27

See exactly what the problem is. I had NSS configured as default H/W controlled with SPI_CR1 bit SSM set to 0. NSS pin (PortA Pin4) was not connected and un-configured (default, floating input). If I configure it as an input pulled-up it works OK. Or, if I configure SSM to software controlled (1) and also set SSI bit of SPI_CR1 to 1 it is OK (allowing PortA Pin4 to be used in future as a I/O pin).

Thanks for pointing me in the right direction!

[robertwood9]

Posted on May 17, 2011 at 13:27

Quote:

On 19-10-2009 at 18:32, Anonymous wrote: See exactly what the problem is. I had NSS configured as default H/W controlled with SPI_CR1 bit SSM set to 0. NSS pin (PortA Pin4) was not connected and un-configured (default, floating input). If I configure it as an input pulled-up it works OK. Or, if I configure SSM to software controlled (1) and also set SSI bit of SPI_CR1 to 1 it is OK (allowing PortA Pin4 to be used in future as a I/O pin). Thanks for pointing me in the right direction! And thanks to you for helping *me* out! As usual the STM32 documentation is as clear as a drunk Chinaman with a lisp talking through a large jumper while sat behind a large door . I simply cannot see why, when you configure the PA4 pin as a GPIO, it interferes with the SPI module! Is all ST micro documentation this terrible? This is the first time I've used an ST micro and am amazed at how vague and badly written it is!

[ccowdery9]

Posted on May 17, 2011 at 13:27

The reason for the poor documentation is that the peripheral documentation is written in isolation from the rest of the chip. This is because the peripherals are re-used on different product families, and it would be a real pain having to re-write every time it's used.

The consequence of this is that sometimes it's very hard to get a decent overview of how all the different parts of the chip interact, as evidenced by the issue you had! FWIW, I have found similar problems with other manufacturers too. Chris.