I have been searching the forum for hours now, without finding anything I can relate (much) to my issue. I have done this test on an Uno R3 SMD and a Feather ESP32 successfully, but the R4 Minima it WILL NOT run right.
It's a simple I2C "scanner" using the i2cdetect library:
#include <Wire.h>
#include <i2cdetect.h>
void setup() {
Wire.begin();
Serial.begin(9600);
Serial.println("i2cdetect example\n");
Serial.print("Scanning address range 0x03-0x77\n\n");
}
void loop() {
i2cdetect(); // default range from 0x03 to 0x77
delay(2000);
}
I have tried both the std SCL and SDA marked pins, and the A4 and A5 pins. Same issue.
Everything is connected 100% the same, using the same code and same test object.
I have compiled, uploaded and tested using my Linux box (latest Kali), as well as Arduino IDE (latest) with serial monitor. Same deal.
I feel like I've been running in circles for the past couple of hours, and I hope someone here can straighten out that circle.
An i2c_scanner is a standard example of the Wire.h library for every arduino platform.. You don't need an additional i2cdetect library for it. Your custom library could be incompatible with Uno R4 core.
I have tried the standard i2c scanner, found on playground (Arduino Playground - I2cScanner), but still nothing with the R4.
Scratching my head like crazy, because I don't really see any reason for it not to work.
Especially since it's bone stock i2c and I'm using the SCL/SDA pins (not the SDA/A4 SCL/A5 pins, though that shouldn't make a difference).
I just happened to have a Minima hooked up to an I2C OLED display here, so I loaded the standard I2C scanner and it worked just fine. Off the top of my head, the only thing I can think you might want to try is adding pullup resistors to the SCL and SDA lines and see if that makes a difference.
I have tried with pullups and without (obv), same deal.
Having searched for even more hours now, I found posts on the forum stating that the built-in pullups could cause havoc, but if that is the case on this R4 is a bit beyond me at the moment.
A bit more information:
What I'm trying to do (and have successfully done with an ESP32), is to connect the Minima to a laptop battery, and read the information stored in the battery, via I2C. Most all laptop batteries have the positive and negative, Clock, Data, and a couple more. I have verified which two are Clock and Data, and I connect those directly to SCL and SDA on R4.
Negative of battery to GND on R4, leaving positive NC (battery is charged and, as mentioned, I could read all the info using the ESP32).
The display is hooked up to A4 & A5, but it works just the same hooked up to SDA and SCL (which they ought to - looking at the schematic it's the same 2 lines just brought out to 2 different places, as you'd expect). No pullups, just the two data lines and power. So no AHA moment in there, I don't think.
Given that the battery communicates just fine with an ESP32 and an R3, it's possibly you've run into a problem with the R4's Wire library. It is still early days.
I've got some other I2C peripherals around here; let me hook up one or two of them and see if any gremlins appear.
Minima has no pull-up resistors on I2C, because they would interfere with the analog pins A4, A5, (which are also connected to SCL/SDA on the "digital" side of the GPIO connectors, bridge between A4-SDA, A5-SCL) .
The resistors R1,R2 (near SCL,SDA pins) are on the schematic, but are not mounted on the board. The I2C device must have its own built-in pull-up resistors.
Note: the I2C interface is compatible with 5V, for 3.3V you need a level converter.
I hooked up a BME280 temperature/pressure/humidity sensor, a DS3231 RTC, a 24C32 EEPROM and the SSD1306 OLED display. Since some of the peripherals were 3.3V only, I used a Sparkfun logic level converter to go between the 5V lines on the R4 and the 3.3V lines on the peripherals. Everything was detected just fine.
Reading the RA4M1 User's Manual, there's some interesting (and confusing on first reading) values in Table 48.4, I/O Vih/Vil.
The minimum Vih for I2C (not SMBus) is listed as VCC x 0.7, or 3.5V. For SMBus I2C, it's 2.2V. Just reading that, if your battery was using 3.3V I2C levels, that could be your problem: Vih is never high enough with a 3.3V peripheral for non SMBus I2C.
Except that the internal pullups (10-50K) are enabled by the Wire library on both SDA and SCL (so they ought to be passively pulling the pins to 5V when they're not being driven low), and, the datasheet goes on to say that the I2C (not SMBus) values are only for pins P205, P206, P400, P401, P407, and P408.
The SDA/SCL pins brought out to the headers are P100 and P101, which are listed as the I2C (SMBus) pins, which means that their minimum Vih should be 2.2V.
I think I either need more caffeine, or a long walk to think about it.
Wow, thank you for diving that far into it! Sorry I haven't been able to respond earlier
I haven't had a chance to do any further testing today, as I've been in meetings all day, but I was sitting there pondering one other thing; What version of Arduino UNO R4 Boards do you have installed? I have version 1.0.4, but I see there are two previous ones, and I saw in one forum post (as well as in an issue on the renesas core GitHub), mention of a bug of some kind in the code, that made certain frequencies plain wrong. If you have either version 1.0.1 or 1.0.2 installed, and I have 1.0.4, I'm tempted to downgrade just to check.
I think I might have a brand new, simple I2C display laying around somewhere, that I will try to locate just to check what results I get on that.
I reduced my caffeine intake (from 20+ cups a day) to about 1 cup a week, circa 4 years ago, or I'd just brew myself a vat full and dive right into the documentation, with testing and everything, and not surface for "air" until I had it working
I'm on 1.0.4, so no joy there. IIRC, there were some issues with specifying anything other than the 3 defined clock frequencies. I haven't looked to see what they've done in the current release.
Jolt Cola was the delivery system of choice back in the day. Walks are way cheaper, and less jittery!
I'm 98% there now
Started tinkering around again today, but cleaned out all the frustration from yesterday (to the degree I can) and started "fresh". I did every test first, with the R3, just so I knew for a fact that it was good.
I compiled the same sketch for R4 and I used 4k7 pullups to 3V3 (had previously used 10k), and this time I (for some reason) got a lot of weird (but at least I got something) information. It was saying hit on >80% of the addresses. I figured (because I had your post in my head) pullup to 5V, and BANG! It came back with a hit on the correct address
This was incredibly funny to me, because I swear I did the exact same thing yesterday, but I'm starting to second guess myself on that one. Today I connected to, compiled on, uploaded using and checked serial, on my Rπ running Kali.
Recompiled the sketch that gets a whole lot of information out of batteries, but this sketch didn't give the output I got using my ESP32 This sketch uses a library from GitHub (called SBS), and I have modified it to work with the current Wire library (SBS was last updated 5 years ago, so it doesn't 100% fit the current Wire lib). Also, the SMS sets the clock at 40000, and it wasn't an issue using the ESP32, but it seems that the R4 is having some issues.
I seem to recall (from heading down the rabbit hole yesterday) that in order to get the latest Arduinos to run sub 100kHz correctly, I would have to make some changes somewhere, but I can't for the life of me (though I haven't headed down the same hole or checked my logg from yesterday) find it again It seems to match the issues I see though, it recognises that there is something on a certain address, but it can't communicate with it correctly.
I have used a 3V3 bus on an R4, just connect the pull up resistors to 3V3. I was driving an MPR121 touch sensor board. Note this is not the Adafruit board that contains level shifters, but a raw MPR121 board.