STM32F103XB: TIM2 CH1 on PA15 conflicts with SPI1 NSS

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

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

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

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

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

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

Thank you very much!

Martin