2017-04-21 12:35 AM
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 #stm32f103Solved! Go to Solution.
2017-04-21 12:50 AM
I think you have run into the issue 2.8.7 of the errata
.PB5 cannot be used as MOSI signal when the I2C1 is enabled.
Use PA5-6-7 for the SPI instead.
2017-04-21 12:50 AM
I think you have run into the issue 2.8.7 of the errata
.PB5 cannot be used as MOSI signal when the I2C1 is enabled.
Use PA5-6-7 for the SPI instead.
2017-04-21 03:17 AM
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!
2017-04-21 03:50 AM
I do agree, CubeMx should not allow this configuration and mark it as conflict.
As of today, this is not implemented.
2017-04-21 04:25 AM
Please report it to the proper division or make an internal ticket about it.
Thanks!
2017-04-21 09:40 AM
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.
2017-04-21 03:13 PM
[OT]
Max,
ES096? I see DocID14574 and en.CD00190234. Please elaborate.
Thanks,
Jan
2017-04-23 09:50 PM
This is the name of the document on st.com and in the MCU finder.
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
2017-04-24 12:56 AM
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 afterhttp://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
2017-04-26 01:05 AM
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.