SPI-CS and a challenge ;-)

[DisruptiveNL]

Hi All,

I am busy to fix the CS SPI problem I have with my STM32L476RG. I have to put CS to GND (ground) to make my SPI-MMC to get to work. But this solution is not consistent.... and not the way to go i recon...

It seems that the STM32 do have some problems with the Hardware NSS.... 

I am using SPI1 [PB4 (MISO), PB5 (MOSI), PB3 (SCLK) and PA3 (NSS/CS ... analogue GPIO?)]

So to try to make the PIN do what I want.... I understand I do not get the concept of talking to pins ;-) I expected a setPINHigh(PIN, number) or something hahaha

Who can help me out with:

- SPI CS?

- Concept of how Nuttx is talking to his hardware on GPIO level...

Thanks

Ben

[Sebastien Lorquet]

Hello

To my knowledge, SPI master on STM32L476 is working perfectly with multiple simultaneous devices on the same bus. There is no obvious problem in this driver unless it was changed very recently.

You do not HAVE TO use the hardware managed NSS pin because it is unusable in most SPI master situations (ALL stm32 and stm32L4 only support very few useless SPI protocols, have a look at the reference manuals). And IIRC, the SPI driver does not even try to use NSS. It is really only useful (maybe) in SPI slave mode, and I have never used that myself.

Moreover... there is only one NSS pin per SPI bus... when you usually have multiple devices per bus! even more useless!

So SPI chip selects are usually NORMAL GPIO pins, and they are managed in the spiXselect functions of the source directory for the board.

Have a look here for the Nucleo-L476RG: https://bitbucket.org/nuttx/nuttx/src/82ff00fabf1e93cdc5ad0dbabb2c83320aa13768/configs/nucleo-l476rg/src/stm32_spi.c?at=master&fileviewer=file-view-default

There is even a SD card example, or at least boilerplate code!

Note that you CAN STILL use the PA3/NSS pin as chip select if you want, but you have to configure it as a normal GPIO!

Sebastien

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Carvalho de Assis]

Hi Ben,

Normally in NuttX the hardware control of Chip Select pin is not used
(except one or two arch that has driver support to it).

Instead it uses a more flexible software controlled GPIO to work as CS.

Then using the hardware controlled CS you are limited to 4 or luckily
8 pins, but using software controlled CS you can use any GPIO pin you
want.

These are the important things you need to know:

You have a board function to configure the GPIO CS pin, i.e.:
void stm32_spidev_initialize(void);

When a SPI transfer is going to start it calls a board specific function, i.e.:

void stm32_spi1select(FAR struct spi_dev_s *dev, uint32_t devid, bool selected);

In this case the boolean variable "selected" is true, but CS usually
needs to be low, then it calls a GPIO write inverting this variable:

stm32_gpiowrite(GPIO_DEVICE_CS_PIN, !selected);

When the SPI transfer finishes this function is called again, but this
time the "selected" variable will be false.
Since the gpiowrite() writes the inverted value of this variable, now
the CS will to go high and the SPI slave device is deselected.

I hope it be useful for you and for other people willing to use SPI on NuttX.

BR,

Alan

[Alan Carvalho de Assis]

Hi Sebastien,

I think this boilerplate code is incorrect, it depends on HAVE_MMCSD,
but it is undefined if SDIO is not defined:

#if !defined(CONFIG_STM32L4_SDIO) || !defined(CONFIG_MMCSD) || \
!defined(CONFIG_MMCSD_SDIO)
# undef HAVE_MMCSD
#endif

The CONFIG_MMCSD_SPI shouldn't depend on SDIO. Because SDIO is not
defined, the CS is never configured.

BR,

Alan

>> <mailto:nuttx+un...@googlegroups.com>.

[Sebastien Lorquet]

Possible, it was probably copied over and again without changes from the first
nucleo port that was ever contributed :)

Sebastien

[Alan Carvalho de Assis]

Yes, unfortunately bad things spread fast like fire.

This is why Mr. Greg have to be very restrictive about code quality
entering into mainline.

[DisruptiveNL]

It is confusing ... and takes a lot of time. And it also seems that there is a lot more going on allready with the stm32l476 nucleo, but never commited?

Op vrijdag 22 juni 2018 15:17:46 UTC+2 schreef Alan Carvalho de Assis: