Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
5 years, 9 months ago.
I2C doesn´t work on F303K8?
I connected a gyro to the I2C pins PB7 and PB_6 to test the I2C but i cant get it working. Same code works with my LPC1768.
Searched around manuals and found something about jumpers SB16 & SB18 but it´s not clear what to do to get I2C working. This is what the Users Manual UM1956 page 20 & 21 says:
Solder Bridges SB16:
ON: STM32 PB6 is connected to CN4 pin 7 for I2C SDA support on Arduino Nano A5. In such case STM32 PB6 does not support Arduino Nano D5 and PA6 must be configured as input floating.
OFF: CN4 pin 7 is used as Arduino Nano analog input A5 without I2C support and CN3 pin 8 is available as Arduino Nano D5.
Solder Bridges SB18:
ON: STM32 PB7 is connected to CN4 pin 8 for I2C SCL support on Arduino Nano A4. In such case STM32 PB7 does not support Arduino Nano D4 and PA5 must be configured as input floating.
OFF: CN4 pin 8 is used as Arduino Nano analog input A4 without I2C support and CN3 pin 7 is available as Arduino Nano D4.
These solder bridges are default ON. Do i need to change these solder bridges to make I2C work? To me it seems like they should be ON.
Someone said in the questions that some I2C commands do work but not others. If I2C doesn´t work on this board it should definatley be listed under Known Limitations at the STM32F303K8 page. It´s like a car where the steering or brakes doesn´t work.
Is there some workaround to get I2C working on this board?
Question relating to:
2 Answers
5 years, 9 months ago.
Hi, I have NUCLEO-F303K8 in original state (without a change on the solder bridges) and the I2C works well on PB7 and PB_6 (D4, D5) with latest mbed lib. Best regards. J.
I do not have any experience with LPC1768 and know nothing about your i2c slave but when you say "Same code works with my LPC1768." can not be a problem with pull up resistors?
posted by 25 Feb 2019Jan, when you say the I2C works well for you on this board with no changes to solder bridges, have you used pull up resistors on the SDA and SCL lines? And if so, what resistor values you choosed?
The LPC 1768 has no built-in pull up resistors, at least not that is enabled by default. I have measured this when i used the I2C for a capacitive touch chip on a display i have.
It was a long time since i tried the gyro sensor on my LPC1768 so maybe i should try it again so i can rule out a damaged I2C gyro, it´s a ITG-3200 3-axis gyro.
However, I have very much other problems now with my NUCLEO-F303K8 board right now. I try uppdate the ST-LINK driver and board firmware but i can´t get it to work even though i follow the instructions to the letter. So until i have figured this update/firmware problem out, the NUCLEO-F303K8 board is not working reliably. I hope i can fix it this weekend when i have some time to spend on this board.
posted by 28 Feb 20195 years, 5 months ago.
I have had a lot of trouble with this too, and it seems that the MBED documentation is wrong. (or at least, very unclear):
According to this doc: https://www.st.com/content/ccc/resource/technical/document/user_manual/e3/0e/88/05/e8/74/43/a0/DM00231744.pdf/files/DM00231744.pdf/jcr:content/translations/en.DM00231744.pdf page 25
By default, I2C is on CN4 pins 7 and 8 (ADC 2 and 3). Signals seem to be appearing on both sides, but not at all reliable on CN3. With a scope on the CN3 pins, clock appeared ok, but data was sunk down to less than 1V, no matter what I did with pull-ups. I had a analog temperature sensor on the analog input on the other side. After pulling that out, I was able to get clean looking clock and data on CN3 PB_7 and PB_6. Even so, my I2C devices were still not working. Only after moving the wires to PA_6 and PA_5 did the I2C devices come alive.
The jumper instructions on Page 20 of the above link are also confusing.
My project requires every analog input, as well as the I2C interface. Does it mean that if I remove both jumpers, I will get both Analog and I2C pins on their respective ports? If so, what reason would they have to make this jumper in the first place?
I don't think "arduino compatibility" is a worthy excuse to design in ambiguity and confusion.