Configure STM32F407 as dual SPI slave device

[Pavlos Stavrou]

Posted on October 18, 2017 at 18:01The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Pavlos Stavrou]

Posted on January 03, 2018 at 13:57

I measured on the pin and as stated also used a logic analyzer on the slave side (STM) and can observer that all signals are as expected.

Here are the register values.

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

SPI1 uses DMA2_Stream3 for Tx and DMA2_Stream2 for RxSPI3 uses pins PC10/PC11/PC12/PA15 as CLK/MISO/MOSI/NSSSPI3 uses DMA1_Stream7 for Tx and DMA1_Stream2 for Rx GPIOA Registers - MODE : 0xA8008228 - TYPE : 0x00000000 - SPEED : 0xCC00C33C - PUPDR : 0x64000100 - AFL : 0xB0050BB0 - AFH : 0x60000000 GPIOB Registers - MODE : 0x00800A8A - TYPE : 0x00000000 - SPEED : 0x00C00FCF - PUPDR : 0x00000000 - AFL : 0x005550BB - AFH : 0x0000B000 GPIOC Registers - MODE : 0x02A00AA8 - TYPE : 0x00000000 - SPEED : 0x03F00FFC - PUPDR : 0x00400000 - AFL : 0x00BBBBB0 - AFH : 0x00066600 SPI1 Registers - CTL1 : 0x00000852 - CTL2 : 0x00000023 - SR : 0x00000000 - DR : 0x00000000 - CRCRP : 0x00000007 - RXCRCR : 0x00000000 - TXCRCR : 0x00000000 - I2SSCFGR : 0x00000000 - I2SPR : 0x00000000 SPI3 Registers - CTL1 : 0x00002851 - CTL2 : 0x00000003 - SR : 0x00000000 - DR : 0x00000000 - CRCRP : 0x00000007 - RXCRCR : 0x00000000 - TXCRCR : 0x00000000 - I2SSCFGR : 0x00000000 - I2SPR : 0x00000002 DMA1 Stream 2,7 Registers - S2CR : 0x00072D17 - S2NDTR : 0x0000000C - S2PAR : 0x40003C0C - S2M0AR : 0x2000EC9C - S2M1AR : 0x2000ECB4 - S2FCR : 0x000000A0 - S7CR : 0x00072D57 - S7NDTR : 0x0000000B - S7PAR : 0x40003C0C - S7M0AR : 0x2000EC6C - S7M1AR : 0x2000EC84 - S7FCR : 0x000000A0 For reference I have used double buffer in circular mode for DMA1 and here are the variables and addresses used. - _tx_buff0 <struct> 0x2000EC6C spi_message_t - _tx_buff1 <struct> 0x2000EC84 spi_message_t - _rx_buff0 <struct> 0x2000EC9C spi_message_t - _rx_buff1 <struct> 0x2000ECB4 spi_message_t DMA2 Stream 2,3 Registers - S2CR : 0x06032D1F - S2NDTR : 0x00000001 - S2PAR : 0x4001300C - S2M0AR : 0x20000154 - S2M1AR : 0x00000000 - S2FCR : 0x000000A0 - S3CR : 0x06032D57 - S3NDTR : 0x00000001 - S3PAR : 0x4001300C - S3M0AR : 0x20000150 - S3M1AR : 0x00000000 - S3FCR : 0x000000A0 For DMA2 circular mode is used, but no double buffering, variables with their addresses used are shown below. - enc_ticks 0x00000400 0x20000150 uint32_t - spiRX 0x00000000 0x20000154 uint32_t

Thank you for your persistence.

[waclawek.jan]

Posted on January 03, 2018 at 14:23

I see nothing suspicious in this.

Can't that pin be damaged? Do you have a different hardware to try?

JW

[Pavlos Stavrou]

Posted on January 03, 2018 at 14:34

I have tried it with 2 different boards. I can safely say that the pin is not damaged.

The boards are custom made. I have tried the same setup with the STM32F407 Discovery board and everything works fine there.

The only difference with our boards is that we use the BGA version of the processor instead of the LQFP one.

[waclawek.jan]

Posted on January 03, 2018 at 14:42

The only difference with our boards is that we use the BGA version

How could you then measure directly on pin? 🙂

Try to set PA4 as GPIO input with pull-up, and in debugger observe, whether it follows the externally applied signal.

JW

PS: btw., PA4 and PA5 are not 5V tolerant

[Pavlos Stavrou]

Posted on January 03, 2018 at 14:49

Well I didn't measure directly on the pin but using a via on the board.

Also, quoting my previous post :

Furthermore, I configured all signals as GPIO Output on the master side and GPIO Input on the slave 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