Configure STM32F407 as dual SPI slave device

Pavlos Stavrou · ‎2017-10-18

Posted on October 18, 2017 at 18:01

The original post was too long to process during our migration. Please click on the attachment to read the original post.

waclawek.jan · ‎2017-10-18

Posted on October 18, 2017 at 20:25

Look at the content of DMA registers. If SPI2 transmits what SPI1 is supposed to transmit, then DMA stream which handles SPI2Tx has its memory pointer set to SPI1's buffer. Other possibility is that the DMA stream which is supposed to handle SPI1Tx has its peripheral pointer set to SPI2's data register.

JW

Pavlos Stavrou · ‎2017-10-20

Posted on October 20, 2017 at 16:07

Hi again.

I have checked all memory and peripheral pointers and all is correct.

I have managed to transmit and receive on both SPI peripherals with the following setup.

SPI1 is configured as slave with DMA on Rx/Tx, using circular mode, double buffering and Hardware NSS.

SPI2 is configured as slave with DMA on Rx/Tx, using circular mode and Hardware NSS.

Both SPI peripherals go to the same Master device SPI port, of course with different GPIOs set as Slave Select Pins.

-------------------------- ---------------------------

| Slave Device | | Master Device |

| STM32F407 | | |

| | | SPI12_CLK |

| SPI1_CLK | --

| SPI12_MISO |

| SPI1_MISO | -- | SPI12_MOSI |

| SPI1_MOSI | -- | SPI1_NSS |

| SPI1_NSS | -- | SPI2_NSS |

| | | |

| SPI2_CLK | -- ----------------------------

| SPI2_MISO | --

| SPI2_MOSI | --

| SPI2_NSS | --

--------------------------

SPI1 and SPI2 CLK,MISO and MOSI signals are connected to respective pins on the Master Device.

The Master chooses the port to communicate using the corresponding NSS signal.

Everything works fine using this setup. I use a STM32F4-Discovery for testing.

However, when I use the same code on my custom board, which uses STM32F407IE (uBGA version), only SPI1 works.

On SPI2, I always receive 0xFFFF on the master side, while on the Slave side (STM32) I never get the HAL_SPI_TxRxCpltCallback to fire. The same function fires when a transaction is complete on SPI1.

Can someone offer any insights as to why the behaviour is different. I have checked that all signals are properly connected on my custom board. Furthermore, I configured all signals as GPIO Output on the master side and GPIO Input on the save side and I can correctly read the pin state (toggled several times). I performed the same test but with GPIO Input on the Master side and GPIO Output on the slave side and again I read the signals correctly. So I can safely say that it is not a H/W issue.

Also, I am a little confused on how STM's SPI and DMA peripherals handle the NSS signal, whether it's h/w or software and in the corresponding examples of STM32Cube_FW_F4_V1.13.0, I have not found something that uses NSS as H/W...

waclawek.jan · ‎2017-10-21

Posted on October 21, 2017 at 17:55

If the SPI in STM32 is used as Slave, the NSS signal effectively gates reception.

Software NSS (SPI_CR1.SSM = 1) means, that the NSS signal to the SPI module is *not* connected to the respective NSS pin, rather, that its level is given by the SPI_CR1.SSI bit.

DMA has no direct relationship to NSS - transmit/receive DMA is triggered by SPI_SR.TXE/SPI_SR.RXNE respectively.

I don't use Cube.

JW

Pavlos Stavrou · ‎2018-01-02

Posted on January 02, 2018 at 19:39

Greetings again and a Happy New Year to all.

After trying all different scenarios to try and resolve the issue I mentioned, I finally took a break to rest my brain a bit. But now it's time to get back to it as we have a project for a client due soon and this is the only thing remaining to be resolved.

Having tried various configurations for SPI and DMA, I have resorted to the setup below.

STM32F407IEH device
SPI1 and SPI3 both used with DMA Rx/Tx and are set-up as Full-duplex SPI Slave (Hardware NSS)

SPI1 uses pins PB3/PB4/PB5/PA4 as CLK/MISO/MOSI/NSS

SPI3 uses pins PC10/PC11/PC12/PA15 as CLK/MISO/MOSI/NSS

SPI1 uses DMA2_Stream3 for Tx and DMA2_Stream2 for Rx

SPI3 uses DMA1_Stream7 for Tx and DMA1_Stream2 for Rx

Pin PA4 can be alternatively used as NSS for SPI3 and PA15 can also be used as NSS for SPI1.

Now the weird part begins.

When either of the two SPI peripherals (SPI1 or SPI3) use PA4 as NSS signal then I have no communication....

In addition, when using STM32CubeMX to generate the intial code for setup I get the warning below for SYS.

System partly disabled conflict with :

SPI1 : Mode Full-Duplex Slave and/or

SPI3 : Hardware NSS Signal Hardware NSS Input Signal

I am using Serial Wire for debug. I do not know and cannot find if this is related to my problem, just thought I should throw out there just in case...

I can also safely say, that the board I am working with has no problem with pin connections as I have tested all of them in GPIO mode and work fine (check was done on the master side as well).

I have also connected a logic analyzer to the SPI pins and I can see that the master is signaling properly.

The problem is that whenever PA4 is used as hardware NSS input the SPI peripheral does not work.

I would apprieciate any help in this matter. Given tha I have no other option for Hardware NSS Input signal for said peripherals, my last resort would be to change to a different processor and scrap all the work done so far.

waclawek.jan · ‎2018-01-02

Posted on January 02, 2018 at 19:55

And what is connected to PA4?

JW

Pavlos Stavrou · ‎2018-01-02

Posted on January 02, 2018 at 20:00

PA4 is the slave select signal for the SPI peripheral and the SS signal of the master is connected to it.

waclawek.jan · ‎2018-01-02

Posted on January 02, 2018 at 22:11

And did you verify that the master actually drives it low while transmitting data, i.e. clocks are ongoing?

What happens if you disconnect it from the master and ground it hard?

JW

Pavlos Stavrou · ‎2018-01-03

Posted on January 03, 2018 at 12:13

Yes I have verified all of the above. I have even grounded the pin and the behaviour is the same.

waclawek.jan · ‎2018-01-03

Posted on January 03, 2018 at 13:07

Did you measure directly on the pin (i.e. can't there be problem with soldering or on the PCB)?

Read out and check or post the relevant GPIO and SPI registers (start with GPIOA registers).

JW