Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 90322ae

Browse files
committedMar 25, 2017
Make I2C work reliably with interrupts
Thanks @marcmerlin and @MartyMacGyver
1 parent a07f984 commit 90322ae

File tree

1 file changed

+6
-4
lines changed

1 file changed

+6
-4
lines changed
 

‎cores/esp32/esp32-hal-i2c.c

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,8 @@
2727
#define I2C_SCL_IDX(p) ((p==0)?I2CEXT0_SCL_OUT_IDX:((p==1)?I2CEXT1_SCL_OUT_IDX:0))
2828
#define I2C_SDA_IDX(p) ((p==0)?I2CEXT0_SDA_OUT_IDX:((p==1)?I2CEXT1_SDA_OUT_IDX:0))
2929

30+
#define DR_REG_I2C_EXT_BASE_FIXED 0x60013000
31+
#define DR_REG_I2C1_EXT_BASE_FIXED 0x60027000
3032

3133
struct i2c_struct_t {
3234
i2c_dev_t * dev;
@@ -49,16 +51,16 @@ enum {
4951
#define I2C_MUTEX_UNLOCK()
5052

5153
static i2c_t _i2c_bus_array[2] = {
52-
{(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE), 0},
53-
{(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE), 1}
54+
{(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE_FIXED), 0},
55+
{(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE_FIXED), 1}
5456
};
5557
#else
5658
#define I2C_MUTEX_LOCK() do {} while (xSemaphoreTake(i2c->lock, portMAX_DELAY) != pdPASS)
5759
#define I2C_MUTEX_UNLOCK() xSemaphoreGive(i2c->lock)
5860

5961
static i2c_t _i2c_bus_array[2] = {
60-
{(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE), NULL, 0},
61-
{(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE), NULL, 1}
62+
{(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE_FIXED), NULL, 0},
63+
{(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE_FIXED), NULL, 1}
6264
};
6365
#endif
6466

9 commit comments

Comments
 (9)

marcmerlin commented on Mar 25, 2017

@marcmerlin
Contributor

Thanks for the quick patch. By the way, I don't claim to understand the patch or know why it fixes anything, I just pasted it from someone else on a forum after verifying it fixes my issues. Hopefully it made more sense to you than it did to me :)

hcs-svn commented on Mar 27, 2017

@hcs-svn

Thanks, that fixed a problem I had. My SSD1306 OLED showed often after some minutes but always after some hours strange things (scrambled content, ...)

With this version the problem is gone.

Jorgen-VikingGod commented on Mar 28, 2017

@Jorgen-VikingGod

I can also report, the fix is working great on my sources too.

me-no-dev commented on Mar 28, 2017

@me-no-dev
MemberAuthor

those are good and bad news at the same time :D the "new" registers are slower than the old ones ;)

MartyMacGyver commented on Mar 28, 2017

@MartyMacGyver
Contributor

Better slower than unusable!

It's frustrating that this is evidently the only way to fix this with the current devices (I understand this compensates for a hardware flaw, right?)

So far this code is working better for me: in my limited tests tonight - with an SSD1306-based 128x32 monochrome OLED as well as an MS5637 baro sensor - it only glitched once... impressive considering it was glitching readily and regularly before.

Per my followup on the forum, I2C on the ESP32 still seems particularly sensitive to interference (noise, RC loads, etc.) but it's definitely much less sensitive when using these slower-but-dependable registers. However, I've got more testing to do to see if this makes the I2C comms truly reliable now.

me-no-dev commented on Mar 28, 2017

@me-no-dev
MemberAuthor

@MartyMacGyver I agree, but it still makes me sad to have to slow things down for them to work. Hopefully later silicons will have this issue addressed.

MartyMacGyver commented on Mar 28, 2017

@MartyMacGyver
Contributor

@me-no-dev At that point some of the more costly workarounds will need to be revisited (particularly these register ones, since they aren't just a one-time cost but a run-time cost). I imagine there's quite a lot of r0 silicon out there already... not sure what devices being sold have r1 silicon at this point.

A good way to handle this would be with compile-time defines that are mediated by the hardware selections in Arduino.

MartyMacGyver commented on Mar 29, 2017

@MartyMacGyver
Contributor

Update: I ran this for several hours with the OLED as well as another sensor in circuit. It didn't glitch and lock up again. Haven't tested it more thoroughly but it's definitely improved.

hcs-svn commented on Mar 29, 2017

@hcs-svn

Update: connected are: SSD1306 OLED, BMP180, BME280, LM75, MCP23008
Running since 56 hours without problems.
That's a completely new feeling when it works several days :-)

Please sign in to comment.