Skip to main content
martonmiklos
martonmiklos
Associate III
April 21, 2017
Solved

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

  • April 21, 2017
  • 5 replies
  • 3369 views
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
This topic has been closed for replies.
Best answer by Max
Posted on April 21, 2017 at 09:50

I think you have run into the issue 2.8.7 of the errata

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/7d/02/75/64/17/fc/4d/fd/CD00190234.pdf/files/CD00190234.pdf/jcr:content/translations/en.CD00190234.pdf

.

PB5 cannot be used as MOSI signal when the I2C1 is enabled.

Use PA5-6-7 for the SPI instead.

5 replies

Max
MaxAnswer
ST Employee
April 21, 2017
Posted on April 21, 2017 at 09:50

I think you have run into the issue 2.8.7 of the errata

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/7d/02/75/64/17/fc/4d/fd/CD00190234.pdf/files/CD00190234.pdf/jcr:content/translations/en.CD00190234.pdf

.

PB5 cannot be used as MOSI signal when the I2C1 is enabled.

Use PA5-6-7 for the SPI instead.

martonmiklos
martonmiklosAuthor
Associate III
April 21, 2017
Posted on April 21, 2017 at 10:17

Dear Max,

Thank you very much for your answer. You have closed a day long investigation with it!

I would recommend two things:

- Please add warning to the CubeMX in these cases.

- I would recommend to add links/notes/whatever to the I2C and SPI sections to the alternate function issues.

Thanks again!

Max
Max
ST Employee
April 21, 2017
Posted on April 21, 2017 at 10:50

I do agree, CubeMx should not allow this configuration and mark it as conflict.

As of today, this is not implemented.

Amel NASRI
Amel NASRI
Technical Moderator
April 21, 2017
Posted on April 21, 2017 at 18:40

Hi

Marton.Miklos

‌,

This issue is reported internally tobe fixed in coming releases. Your recommendations will be taken into consideration for sure.

Thanks Max for your prompt help.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Carlo Agrusti
Carlo Agrusti
Associate II
April 26, 2017
Posted on April 26, 2017 at 10:05

Thanks to @waclawek.jan I discovered a similar issue also on a STM32F103RET7 mcu, with the main difference that I DID NOT CONFIGURE I2C1 (even if I designed a I2C bus on PB.06/PB.07). My configuration is as follows:

0690X00000606scQAA.png

And I had to disable AIN+DMA, USART1, USART3 and all the timers to have MOSI properly moving (well, the M95128 eeprom is still not answering to the Read Status Register request, but this is another issue i have to work on). I'm now in the process of selectively enable the other functions in order to discover the interference with SPI1.

Max
Max
ST Employee
April 26, 2017
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
Carlo Agrusti
Associate II
April 26, 2017
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?

Carlo Agrusti
Carlo Agrusti
Associate II
April 26, 2017
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.

Terms & ConditionsAccessibility statement