STM32F103XB: TIM2 CH1 on PA15 conflicts with SPI1 NSS

[Kolja Waschk]

Posted on January 09, 2018 at 18:32

Hi,

Using CubeMX, I configured SPI1 on a STM32F103T8Ux as full-duplex master mapped on PB3..PB5, with hardware NSS (on PA15) disabled (set to

SPI_NSS_SOFT

in spi.c).

So, PA15 should be available for TIM2 CH1 PWM output. But no PWM activity can be seen on PA15 (it stays low) until I disable SPI1 peripheral (using

HAL_SPI_DeInit()

or just

__HAL_RCC_SPI1_CLK_DISABLE()

).

Did I miss some errata?

Kolja

#stm32f103 #stm32f1 #tim2 #conflict #errata #spi #stm32 #nss #spi1

[MStim]

Hi,

I'm experiencing nearly the same problem with the bluepill (STM32F103C8Tx).

I configured SPI1 as "Receive Only Slave" with SPI1_SCK on PA5 and SPI1_MOSI on PA7. So PA6 should be free for PWM-generation with TIM3_CH1. As soon as I activate the SPI1 clock with __HAL_RCC_SPI1_CLK_ENABLE() pwm-generation stops (Pin is high) and restarts on deactivating the SPI1 clock with __HAL_RCC_SPI1_CLK_DISABLE().

Any news?

Thanks,

Martin

[Bob S]

Please post your SPI related code (init, etc.) code, otherwise we could guess all day long.

[Tesla DeLorean]

Honestly the F1 is a very clunky design, the pin level remapping of pins is a lot better on subsequent designs.

[waclawek.jan]

Remapping on 'F1 works for all pins of a peripheral at once, regardless of whether that peripheral uses a particular pin or not. In other words, once you set AFIO_MAPR.SPI1_REMAP = 1, and enable SPI1 clock in RCC, pins PA15, PB3, PB4 and PB5 belong to SPI1, even if they are not used in SPI1. Similarly, once you enable SPI1 clock with AFIO_MAPR.SPI1_REMAP = 0, pins PA4-PA7 belong to SPI1. There may be clashes and undefined functioning may result from attempting to remap the same pin to several peripherals at once.

JW

[MStim]

Thanks a lot! This explains my problem! Is this also an issue in other STM32 families or do they use other methods of pin remapping?

Martin

[waclawek.jan]

No. As Clive said above, the 'F1 was the first STM32 family historically, and the GPIO remapping is one of its "hatching" problems. All other STM32 families have sort of an AF "matrix" - check out datasheet of any STM32 of any other family.

The other families also try to maintain pin compatibility to a certain extent; again, check out those datasheets.

JW

[MStim]

Thank you very much!

Martin