SPI1 and SP3 communications on STM32F103RF

[denisb-popov]

Posted on November 18, 2015 at 10:21

Is it possible to connect SPI1 to SPI3 internally (by remapping SPI1 to PA15, PB3, PB4, PB5 or somehow else)? Didn't find any information about: ''remapping SPI1 disconnects SPI3 from PA15, PB3, PB4, PB5''. Also didn't find any schemes of how peripherals sharing the same GPIO pins are connected internaly.

I'm not using standard peripheral library provided by st, my code is doing the following: 1. Enabling peripherals in RCC domain: GPIOA, GPIOB, AFIO, SPI1, SPI3, DMA1, DMA2 - enabled 2. Remapping peripherals in AFIO domain: Debug mode: JTAG-DP Disabled and SW-DP Enabled, SPI1 remapped 3. Configuring GPIOA, GPIOB: PA15, PB3, PB4, PB5 - alternate functions Push-Pull, 50 Mhz 4. Configuring SPI1: slave, SSM = 0, SSOE = 1, other equal to SPI3(doesn't matter) 5. Configuring SPI3: master, SSM = 0, SSOE = 1, other equal to SPI1(doesn't matter) SPI1 and SPI3 working with DMA1 and DMA2

respectively.

6. Configuring and enabling DMA1_CH3(SPI1_TX), DMA1_CH2(SPI1_RX), DMA2_CH2(SPI3_TX), DMA2_CH1(SPI3_RX) 7. First starting SPI1: DMA1_CH3 is writing 1 byte to DR, thereby clearing TXE flag 8. Then starting SPI3: DMA2_CH2/DMA2_CH1 writing/reading all packet to DR (all rx bytes = 0) 9. Next SPI1 and associated DMA channels remain unchanged.   Don't see SCK, NSS, MOSI, MISO signals with the scope while SPI3 works (p.8) PS: when controlling PA15, PB3, PB4, PB5 as GPIO's they are switching fine!   #stm32f103

[denisb-popov]

Posted on November 18, 2015 at 12:52

Help! Please

 

[denisb-popov]

Posted on November 18, 2015 at 14:33

After changing configuration to:

SPI1 - master SPI3 - slave All 4 DMA channels used in communication have successfuly finished their transfers and master have successfuly transmited data to slave. But slave haven't transmitted data to master.... Does anyone have an idea why?   

[Tesla DeLorean]

Posted on November 18, 2015 at 18:55

Does anyone have an idea why?

Not really, and I'm having a hard time understanding the point of this exercise. The exact logic at work in the pin driver, and multiple alternate functions isn't well defined, and likely to be a mix of AND, OR, and MUX, and inputs fanned out to multiple nodes. The errata covers a bunch of issues/clashes this has caused. I'm not sure it's worth a lot of time probing the internal logic to find out.