I have been trying in vain to get a QMC5883 and a MPU-6500 to communicate with a BluePill probable clone via i2c connection on PB6(SCL1) and PB7(SDA1). Initially I tried using the appropriate libraries but since I got no success I then tried an i2c scanner program shown below to see if this could at least read the address. This did not work as well. Code is the following:
#include <Wire.h>
void setup() {
Wire.begin();
Serial.begin(115200);
while (!Serial){}; // Wait for USB Connection
Serial.println("\n\nI2C Scanner");
}
void loop() {
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for (address = 0; address < 127; address++) {
Wire.beginTransmission(address);
error = Wire.endTransmission();
Serial.println(address);
if (error == 0) {
Serial.print("I2C device found at address 0x");
if (address < 16) Serial.print("0");
Serial.println(address, HEX);
nDevices++;
} else if (error == 4) {
Serial.print("Unknown error at address 0x");
if (address < 16) Serial.print("0");
Serial.println(address, HEX);
}
delay(50);
}
if (nDevices == 0) {
Serial.println("No I2C devices found\n");
} else {
Serial.println("done\n");
}
delay(3000); // Wait 3 seconds for next scan
}
Since the BluePill F103C8 board may be suspect, I decided to use a new WeActStudio F411Ret6 board using the same pins but the result was exactly the same. Since I read that the internal pullups on these 2 pins may not be sufficiently low I also installed, first 8.2k pullups and then 4.7k pullups but still no luck.
@jim-p , There is no difference with or without pullups. Note that I am reluctant to connect the pullups to the 5v rail for the following reasons. The STM32 boards as well as the sensors are all fed from a 5v supply but each has regulator which drives the actual chips to 3.3v. Although it is clear that PB6 and PB7 on the STM's are 5v tolerant it is not clear if the SDA and SDL on the MPU-6500 are. For this reason I pulled up the resistors to the 3.3v rail only.
Finally I hooked up a DSO on the pins in question and it is clear that with or without the resistors pulled up, the pins are stuck at 3.3v with no activity.
I wonder if there has been some changes made to the STM32duino package in recent upgrades which would require some other method of firing up the i2c bus!!! I recently faced a similar issue when trying to fire up the Serial2 port. It resulted that I had to enable it using "Uart Serial2(PA3,PA2);" before I could get going.
You are not. The pullups on that board are connected to the output of the onboard 3.3V regulator. Other people have reported problems using the MPU6050 and MPU6500 boards when using 3.3V for power.
The F411 board is new. I have only tested it with the MPU6500 and the QMC5883. The latter forms part of the M100-5883 module which combines a GPS and 5883 in one module. The GPS part which uses Rx and TX works well with both F411 and F103 board. The 5883 uses separate SDA SCL lines.
How do I test the 5883 on its own?
I have now disconnected the MPU-6500 completely and ran the scanner on the f411 on its own with the DSO connected to the SCL pin. I expected to see some clock pulses on this pin. With no external pullup the pin remains low which implies it is set up as open drain. Strapping a 5k to the 3.3v takes the pin to 3.3v but no clock pulses.
@kmin, I have now tried your .setSDA() , .setSCL() suggestions with the same result. I don't think I have any issues with the soldering/wiring. In the end I am now only experimenting with the bare F411module.
Incidentally I went round all the pins with the DSO and there was only activity on PA11 and PA12 which are connected to the USB type C socket. There is also a 200ns single pulse on PA8 which appears to be connected to the SDcard socket which on the drawing is labelled "TF interface".
@kmin The board came preloaded with Blink like utility . As I understand the difference between this and the standard blink is that on this board when you press the User key the Blinking frequency changes and it does.
@jim-p , I have tested the 5V option with the standalone module and still no activity on the SCL SDA pins.
Since the F411 didn't work for you either, I decided to dust off an old Blue Pill, hook it up to a GY-80 (which I remembered as having a few I2C devices on it) and load up your I2C scanner sketch.
And the result (after commenting out the line that printed every address):
I2C Scanner
Scanning...
I2C device found at address 0x1E
I2C device found at address 0x53
I2C device found at address 0x69
I2C device found at address 0x77
done
So the sketch is fine, the selected pins are fine, and it sees the I2C devices. No pullups other than those on the GY-80. I repeated the process with a bare BME280 board which didn't have an onboard regulator or level shifting and it too was detected.
Since both boards failed to detect your I2C devices, I'd suggest double checking and triple checking your wiring and soldering on the headers.
@van_der_decken , Thank you very much for taking the trouble of setting a BluePill and test the sketch.
Regarding wiring/soldering issues I should inform that I have been playing with electronic projects for the past 40 years, so such issues although of course possible are not very frequent.
Nonetheless in order to dis spell any doubts in this regard I altered the standard Blink sketch to set PB6,7 as outputs and toggled these outputs in conjunction with the LED ( on my board it is PB2) pin. I then hooked up the scope to monitor the signals as they arrive at the SDA,SCL pins at the MPU6500 side.
I can confirm that the pins toggled between 3.3v and gnd in synchronism with the LED and therefore it is reasonable to assume that connections are not the issue.
Given that you have had no problem with your setup, may I ask you to check which version of STM32duino core you have installed and tested with?
This is because, very recently, I had exactly similar issues with enabling Serial2 where, sketches which did not work on my installation worked well on other people's. It then resulted that my STM32duino core is a version which came out only about a month ago and indeed this version required a different method of firing up Serial2.
40 years, huh? Well I've been at it a little longer than that. And I still make mistakes. So when something doesn't work, I check everything I've done before assuming that something else is the cause.
Good luck working it out. I don't think my help will be of any further use here.
It would appear I offended you. Sorry about that. That was not my intention. You will note that despite my assertion, I still took your advice and tested my wiring.
Can you at least confirm which version of STM32duino core you tested with? Thanks.
