cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103 no MOSI output on SPI1 when using I2C1 with CubeMX generated code

martonmiklos
Senior
Posted on April 21, 2017 at 09:35

I have generated a project for an STM32F103C8T6 using CubeMX 4.20.1.

I am using i with the 1.4.0 of the STM32CubeF1 library.

I am using the unmodified generated code to send out data in the main loop.

The CubeMX configuration is the following for the pins:

0690X00000606dlQAA.png

I2C on PB-7 SPI on the PB3-5 (MISO is unused). The generated GPIO initialization code looks ok for me.

If the I2C1 module is enabled there is not any output on the MOSI line even if sending non 0xFF data:

0690X00000606pxQAA.png

I have narrowed down the source problem to the __HAL_RCC_I2C1_CLK_ENABLE in the HAL_I2C_MspInit.

If I remove that the MOSI output will work as expected. (Of course in this way the I2C peripherial will not work):

0690X00000606kAQAQ.png

I have already checked the errata, but have not found any relevant. The generated codes seems to do what they supposed to, but I am not really sure where to look for the problem source.

Any help would be deeply appreciated!

#spi #cube-mx #stm32 #i2c #stm32f103
12 REPLIES 12
Carlo Agrusti
Associate II
Posted on April 26, 2017 at 11:45

Ok, a quick update: it seems that the PWM outputs (TIM1_CH1, TIM8_CH1 and TIM3_CH3) affect the behaviour of SPI1. These are bad news for me, since my board heavily relies on these PWM's; can anybody suggest me a STM32 not affected by this annoying issue?

Posted on April 26, 2017 at 10:33

You should look at

https://www.google.com.sg/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj_-4O02cHTAhUIWBoKHdt4Du8QFgggMAA&url=http%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Ferrata_sheet%2Fcd00197763.pdf&usg=AFQjCNESp79KlLDdyl-Wbi8XBIHkIvoNnQ

 Section 2.8: Alternate function for this device.

There are a few constrains on alternate function usage on this device series.

As demonstrated by the previous messages above, this is not handled automatically by CubeMx at this time (rev 4.20.1). 

Carlo Agrusti
Associate II
Posted on April 26, 2017 at 12:40

Ok, I traced back the interference to TIM8_CH1: if I don't configure it (with following code) MOSI works as expected.

/*
 * Enabling TIM8 clock
 */
 RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM8, ENABLE);
/*
 * Enabling GPIOC clock
 */
 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);
/*
 * Configuring TIM8_CH1 on PC.06
 */
 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6;
 GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
 GPIO_Init(GPIOC, &GPIO_InitStructure);�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

I think this is a new errata for STM32F103RET7.