Does CubeMX code generator has some problems in I2C or not?

[hamid]

Posted on February 19, 2015 at 10:31

I'm a beginner in stm32Fx. I'm using Keil IDE and cubeMX code generator.

I've used I2C1 and I2C3 in my board with stm32f407 microcontroller and used cubeMX for generating initial codes. I've tried to use I2C3 and it didn't work but I2C1 worked correctly.

I've tested cubeMX code generator in my stmf429 discovery board and the same issue. I2C1 worked and I2C3 didn't work.

I have found a website that has very good libraries with drivers but not as complete as stm's, in that libraries all I2Cs work properly.

Does CubeMX code generator has some problems in I2C or not?

Thank you Best regaurds #auto-corrected-dyslexia #cubemx #i2c-stm32f4

[Amel NASRI]

Posted on February 19, 2015 at 13:32

Hi Hamid,

Please explain how exactly I2C3 doesn't work? Is there any error flag set?-Mayla-

[montagnanigiovanni]

Posted on February 20, 2015 at 14:29hi, i'm experiencing the same problem. i2c3 simply doesn't provide signals on the output pins. they are simply pulled up and stay still.i need those pin working soon.any help would be very appreciatedthank you

[Tesla DeLorean]

Posted on February 20, 2015 at 18:29

Review the pin, perishable and clock configurations of the ''generated'' code. The search space here is relatively contained.

[Tesla DeLorean]

Posted on February 20, 2015 at 20:54

Review the pin, perishable and clock configurations of the ''generated'' code. The search space here is relatively contained.

What did I do there, I think Chrome auto-corrected on me, should of course be peripherals.

[Osto]

Posted on February 20, 2015 at 23:15

Hi,

I had the same problem with I2C3 and STM32F4-Discovery board.The I2C communication reports always bus busy error.I couldnt find any solution for that, I changed to use I2C1 and I2C2.Regards

[Tesla DeLorean]

Posted on February 21, 2015 at 00:20

I had the same problem with I2C3 and STM32F4-Discovery board. The I2C communication reports always bus busy error.I couldnt find any solution for that, I changed to use I2C1 and I2C2.

Well that does sound like a pin/mux issue, the I2C peripheral is very sensitive to low pins.

[montagnanigiovanni]

Posted on February 21, 2015 at 08:43

hello i think that is not a board-specific problem because i encountered it with my own board, with a discovery f4 and i've tried to use another microcontroller (a stmf401 nucleo board ) and find out the same problem. clive, have you ever managed to use the i2c3? 

what do you mean with sensitive to low pins? my pins stay fixed pull-upped. do you think that i can solve this problem trough software or do i have to patch the board?thank you Giovanni

[Tesla DeLorean]

Posted on February 21, 2015 at 12:37

What I'm suggesting is that you carefully review the generated code, based on the thread direction, especially the code that programs the AF mux, namely GPIOx_AFRL/H which routes the peripheral function to the pins. Should be AF4 for I2C3

Once clearly identified to ST, I'd expect them to fix it. They want specific illustration, either through the .IOC file, or code fragments. Believe me this saves a lot of time trying to recreate failing cases, however simple they may be appear to be cause. Assume they are busy, the things which are easy to fix will get addressed first, or more quickly. The I2C peripheral is very sensitive to what it thinks it sees at it's pins, this can be impacted in how the peripheral and surrounding pin paths are initialized (ordering/sequence/enablement). If things are muxed to the correct source, etc. If it sees low pin levels, or glitches, from whatever source, it likes to get stuck in the busy state. Compare and contrast generated code for pin/peripheral cases that work against those that fail.

[montagnanigiovanni]

Posted on February 21, 2015 at 13:10thank you clive, but alternate pin function 4 is the first thing i've checked. i've also checked if the right bit of the clock enable of the peripheral is enabled.on monday i will try to reset the peripheral bevore trying to trasmit.probably is like you said, a glitch makes some unexpected flag to turn on and the code gets stuck in the busy state.the thing i find strange is that is the same for the stm32f401.. bah!i'll also take a look to the older libraries, maybe they have some more robust initializiation procedure?thank youGiovanni