Issues with I2C? Only 1 of 4 devices found by i2cscanner.c

[Scalpel78]

Hi,
I'm playing around with I2C using a Sparkfun ESP32 Thing and Kolbans code for i2cscanning (https://github.com/nkolban/esp32-snippe ... cscanner.c)

I've got a TMP102 (temperature), HMC6352 (compass), MPL3115A5 (altitude) and a ADXL345 (accelerometer). I've tried hooking up all at the same time, as well as testing them individually.

The only device that is found by the i2cscanner.c is the HMC6352 (at address 21). None of the others show up.

The boards have onboard pull-up resistors, but I've experimented with adding both 2k2 and 4k7 resistors as well, but no change.

Has anyone else tried these (or other) I2C devices with Kolbans i2cscanner?

[kolban]

Ive had good luck so far "scanning" I2C devices. So far, all the I2C devices I have connected has shown up as advertized. Do you have access to a logic analyzer you can attach to the SDA and SCL lines?

The scanner is really simple code. When a master starts a transaction and supplies the address of the device, the devices is supposed to respond with an "ACK" ... if there is no device, we will get a "NACK". The I2CScanner runs through all the legal addresses of attachable I2C devices and, for each one, starts a transaction and looks for the ACK.

The sample code includes setting pull-ups for the SCA and SDA lines so, in principle, there should be no need for additionals.

[Scalpel78]

Yes, I have a Saleae Logic 4. I hooked it up earlier, and in the I2C analyzer section it listed a hole lot of NAK's, and a single ACK (for 0x21). I'm unsure as what more info I should look for in the analyzer, and what logiclevels I'm supposed to see.

[Scalpel78]

Tomorrow I can try to hook up a Teensy 3.2 instead of the ESP32, and run an Arduino-based I2C scanner on the Teensy to see if that gives different result.

[ESP_Sprite]

You may also want to put external pull-ups on the SCL and SDA lines if you haven't done that; 3K-10K'ish should work fine. The internal pull-ups are (iirc) an order of magnitude larger, so they may not be able to pull up the lines in time.

[kolban]

Hmmm ... this feels pretty important. The specs for I2C suggest a pull-up of about 4.7K Ohms. Reading the docs on the I2C driver, I see the ability to software specify I2C master pull-ups via:

http://esp-idf.readthedocs.io/en/latest ... pullup_enE

and

http://esp-idf.readthedocs.io/en/latest ... pullup_enE

If there is truth in having to add external pull-ups then we probably need to make that pretty explicit. If one were to rely on the documentations, one would believe that setting scl_pullup_en and sda_pullup_en would be sufficient. So far, Ive played with about half a dozen distinct I2C slave devices with no external/additional pull-ups other than specify the software drivers to perform the pull-ups and Ive not had any problems. Maybe I've just been lucky so far ... however I think its probably important that we learn whether external pull-ups are required or not.

[Jakobsen]

Hi
I did not have i2c communication with out additional external pull up. I have looked at scope plot with and with out 4k7 external pull.
The esp32 internal pull is weak - looks like 10-15k

I will post some plot next time I have it up running.

/j

[Scalpel78]

Hi guys, so I tried the same tests, but this time using a Teensy 3.2.

It was able to detect all four devices!
So ESP32 was able to find device at 0x21, while Teensy found devices at 0x21, 0x48, 0x53 and 0x60.

Regarding the external pull-up resistors; yes, those are important, and all the breakout boards I'm testing with have them. Albeit in varying sizes, but they are there.

I fired up the Saleae Logic 4 analyzer, and I see two very different results when scanning via the Arduino sketch and when scanning using Kolbans scanner.

Here is the I2C result from where the Arduino scanner finds the device at 0x60. Looks all pretty



Now, here is the result from the ESP32 scanner. At the start it looks all fine and dandy;



However, a bit further along it starts getting all jarbled. Notice that from around 0x40 a lot of reads for 0x67 keeps popping up.


So something fishy is going on here. Can it be that the devices you guys have been using have a low address, while the once that aren't showing up are in the high address range?

[Scalpel78]

Got it working!

In Kolban's i2c scanner I changed this line from

Code: Select all

espRc = i2c_master_cmd_begin(I2C_NUM_0, cmd, 10/portTICK_PERIOD_MS);

to

Code: Select all

espRc = i2c_master_cmd_begin(I2C_NUM_0, cmd, 100/portTICK_PERIOD_MS);

With that change all the four devices were detected. As I understand it the last parameter of i2c_master_cmd_begin is "maximum wait ticks", which probably means the maximum time a device can use to respond before it's considered a timeout.

[kolban]

What a great catch. Ive changed the code to increase the time and the next push will see the change go live. Needing such a high value seems odd ... so lets see if we can't figure out what is going on. The I2C bus should be running at 100KHz ... this means that the clock ticks 100,000 times a second ... or equivalently, 10uS period. The way I understand the ESP-IDF framework to work is that we build a sequence of I2C "commands" using the primitive I2C parts such as <start>, <write>, <read>, <end>. These are accumulate and then we execute an "i2c_master_cmd_begin" which then "does whatever is necessary to cause the ESP32 hardware to execute the I2C commands by taking our instructions and driving CLK and SDA appropriately".

Since the hardware is taking the command sequence and driving the transmission and reception of data asynchronously to application flow, if all we did was ask the ESP32 hardware to drive I2C, we wouldn't "know" when the I2C transaction had completed unless we polled some flag in our own logic. To make this simpler, the i2c_master_cmd_begin blocks the caller until such time as the I2C transaction has completed. Putting it another way, it blocks until the ESP32 hardware has transmitted/received the requisite number of commands/data. Since the clock is ticking at 100KHz, then 1ms would be 100 clock cycles and 10ms would be 1000 clock cycles. If we assume a write request to slave device is a start (1 clock cycle), an address (7 clock cycles), a write flag (1 clock cycle) and a stop (1 clock cycle) ... then that would seem to say that our simple transaction should take 10 clock cycles ... which would be 100us.

For any given I2C sequence of commands, we can assume that the duration needed to send/receive would be constant ... it would be the number of clock cycles needed * the clock speed.

Now we look again at the i2c_master_cmd_begin() function. It has a final parameter which is the number of FreeRTOS clock ticks which is the maximum amount of time that i2c_master_cmd_begin() should block for. But wait ... why do we need that? It would appear that the duration from the start of the I2C request to the end is fixed for any given transaction? What I think is going on is the idea that since the I2C transaction is processed asynchronously, we may not know "exactly" when an I2C transaction is sent to the wire and we would also have to be signaled when the transaction completes. Since we are running under FreeRTOS, we have the notion that we can no longer wait small amounts of time with fine grained granularity. For example, we can't sleep in a task for 100us without blocking all other work. Since the default FreeRTOS tick rate is 1ms, we should assume that is the minimum amount of time where when our blocking task relinquishes control to another task that it may get control back (from another busy task).

By specifying 10/portTICK_PERIOD_MS as the timeout value of i2c_master_cmd_begin() that (in principle) should have been enough time ... but obviously wasn't.

By increasing the maximum amount of wait time for i2c_master_cmd_begin(), we find that we are allowing the task that is blocked waiting for the event from the hardware that indicates that the I2C transaction has completed to take longer.

A couple of other questions:

1) In the logic analyzer traces, what does the CLK period show as actually on the bus? Are ticking at the expected 100KHz?
2) The FreeRTOS tick period is configurable. What value is in effect for your compiled application? (see make menuconfig)