ESP32 Official Forum
https://esp32.com/
It's not so much the code that matters as the device under test does. A display gets far more traffic than a sensor, so the glitches are more obvious and occur much more quickly. Some kind of loopback test might work better (or it might not work at all) but I've not devised one yet.If you can point us to the code and a description of the setup (what kind of display we need to use), I'll pass this info along so that we can see if the hardware is generating invalid waveforms at some point.
While I am concerned about the unusual sensitivity of I2C on the the ESP32 to load (it takes very little to make the output frequency vary, especially at 400kHz) I don't think that's the main issue.I just want to drop a line here. I'm also seeing similar problems like MartyMacGyver. In my case I'm using an I2C based IR-sensor. It works for a few minutes, and then the ESP32 looses connection with the device.
I've tested the IR sensor by itself, and with other I2C devices connected as well. Lately I've been using my custom made PCBs when developing. They use 1k pullups.
I assume the sensor is being tested in isolation so no other i2c devices are present. I don't see pull-up resistors on the breakout board I looked at (http://www.robot-electronics.co.uk/file ... e02b_e.pdf) - what value of pull-up resistors are you using for this? (Typical value is 4.7Kohm).
Edit: One reference I looked at was https://github.com/NorbotNorway/TeensyAndGP2Y0E02B... I just noticed you're a contributor there so you're probably already aware of all this. Still, would be good to know what value you used in this case (1K is pretty strong IMHO but there's a lot that goes into that calculation - and as long as it's somewhere between 1K and 4.7K I don't think it really matters to the ESP32 problem).
Code: Select all
Wire.requestFrom(ADDRESS, 2);
while (Wire.available() < 2);
Code: Select all
// Copyright 2015-2016 Espressif Systems (Shanghai) PTE LTD
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#include "esp32-hal-i2c.h"
#include "esp32-hal.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/semphr.h"
#include "rom/ets_sys.h"
#include "soc/i2c_reg.h"
#include "soc/i2c_struct.h"
#include "soc/dport_reg.h"
// #define DR_REG_I2C_EXT_BASE 0x3ff53000
#define DR_REG_I2C_EXT_BASE_FIXED 0x60013000
// #define DR_REG_I2C1_EXT_BASE 0x3ff67000
#define DR_REG_I2C1_EXT_BASE_FIXED 0x60027000
//#define I2C_DEV(i) (volatile i2c_dev_t *)((i)?DR_REG_I2C1_EXT_BASE:DR_REG_I2C_EXT_BASE)
//#define I2C_DEV(i) ((i2c_dev_t *)(REG_I2C_BASE(i)))
#define I2C_SCL_IDX(p) ((p==0)?I2CEXT0_SCL_OUT_IDX:((p==1)?I2CEXT1_SCL_OUT_IDX:0))
#define I2C_SDA_IDX(p) ((p==0)?I2CEXT0_SDA_OUT_IDX:((p==1)?I2CEXT1_SDA_OUT_IDX:0))
struct i2c_struct_t {
i2c_dev_t * dev;
#if !CONFIG_DISABLE_HAL_LOCKS
xSemaphoreHandle lock;
#endif
uint8_t num;
};
enum {
I2C_CMD_RSTART,
I2C_CMD_WRITE,
I2C_CMD_READ,
I2C_CMD_STOP,
I2C_CMD_END
};
#if CONFIG_DISABLE_HAL_LOCKS
#define I2C_MUTEX_LOCK()
#define I2C_MUTEX_UNLOCK()
static i2c_t _i2c_bus_array[2] = {
{(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE_FIXED), 0},
{(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE_FIXED), 1}
};
#else
#define I2C_MUTEX_LOCK() do {} while (xSemaphoreTake(i2c->lock, portMAX_DELAY) != pdPASS)
#define I2C_MUTEX_UNLOCK() xSemaphoreGive(i2c->lock)
static i2c_t _i2c_bus_array[2] = {
{(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE_FIXED), NULL, 0},
{(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE_FIXED), NULL, 1}
};
#endif
Well, since I just made the change, I didn't want to jinx itI'll give that a look - define "much better" though... are you seeing errors still, but fewer, or no problems at all (so far)?
