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

[martonmiklos]

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:

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:

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):

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

[Max · Accepted solution]

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]

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]

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.

[martonmiklos]

Posted on April 21, 2017 at 11:25

Please  report it to the proper division or make an internal ticket about it.

Thanks!

[Amel NASRI]

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

[waclawek.jan]

Posted on April 21, 2017 at 22:13

[OT]

Max,

ES096? I see DocID14574 and en.CD00190234. Please elaborate.

Thanks,

Jan

[Max]

Posted on April 24, 2017 at 04:50

This is the name of the document on st.com and in the MCU finder.

http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f1-series/stm32f103/stm32f103c8.html

Don't try to find a logic behind the multiple naming, I don't think there is any...

I guess the document is older that the naming convention: (ESxxxx for erratas, DSxxxx for datasheets, UMxxxx for user's manual, ...) so its old cryptic name is still used inside the document.

Max

[waclawek.jan]

Posted on April 24, 2017 at 07:56

Max,

This is the name of the document on st.com and in the MCU finder.

I know that of course; that was not a question.

Don't try to find a logic behind the multiple naming, I don't think there is any...

That's OK. Oh, of course it is not, but... for time being... let's just call it force majeur.

I guess the document is older that the naming convention: (ESxxxx for erratas, DSxxxx for datasheets, UMxxxx for user's manual, ...) so its old cryptic name is still used inside the document.

So that convention was conceived after November 2015? Or was it after

http://www.st.com/resource/en/errata_sheet/dm00148061.pdf

or after

http://www.st.com/resource/en/datasheet/stm32f070c6.pdf

(a random pick)? And why can't the ES's number match the DS's number and that match the DB's number, documents which apparently all belong to the same die (which, btw, seem to have it's own number too?)

These are not questions either.

You're making it unnecessarily harder not only to ourselves but to yourselves too.

Jan

[Carlo Agrusti]

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:

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.