I2C Communication Fails with DS3231 RTC Module

[gailu]

Hi Experts,

Setup: SDK version 2.0.0
Hardware: ESP-12E

I have connected DS3231 RTC module http://www.ebay.in/itm/252641600523 with ESP-12E as follows

Code: Select all

ESP-VCC -> DS3231-VCC
ESP-GND -> DS3231-GND
ESP-GPIO2 -> DS3231-SDA
ESP-GPIO14 -> DS3231-SCL


I hope my connections are correct as per i2c_master.h

Code: Select all

#define I2C_MASTER_SDA_MUX PERIPHS_IO_MUX_GPIO2_U
#define I2C_MASTER_SCL_MUX PERIPHS_IO_MUX_MTMS_U
#define I2C_MASTER_SDA_GPIO 2
#define I2C_MASTER_SCL_GPIO 14
#define I2C_MASTER_SDA_FUNC FUNC_GPIO2
#define I2C_MASTER_SCL_FUNC FUNC_GPIO14C FUNC_GPIO14


I have following code in user_main.c.

Code: Select all

void user_rf_pre_init(void)
{
}

uint32 ICACHE_FLASH_ATTR
user_rf_cal_sector_set(void)
{
    enum flash_size_map size_map = system_get_flash_size_map();
    uint32 rf_cal_sec = 0;

    switch (size_map) {
        case FLASH_SIZE_4M_MAP_256_256:
            rf_cal_sec = 128 - 8;
            break;

        case FLASH_SIZE_8M_MAP_512_512:
            rf_cal_sec = 256 - 5;
            break;

        case FLASH_SIZE_16M_MAP_512_512:
        case FLASH_SIZE_16M_MAP_1024_1024:
            rf_cal_sec = 512 - 5;
            break;

        case FLASH_SIZE_32M_MAP_512_512:
        case FLASH_SIZE_32M_MAP_1024_1024:
            rf_cal_sec = 1024 - 5;
            break;

        default:
            rf_cal_sec = 0;
            break;
    }

    return rf_cal_sec;
}

/******************************************************************************
 * FunctionName : user_init
*******************************************************************************/
void user_init(void)
{
    uart_reattach();

    os_printf("\r\n\r\n============SDK version:%s============\r\n", system_get_sdk_version());

    i2c_master_gpio_init();
    i2c_master_init();

    i2c_master_start();

    // write address & direction
    i2c_master_writeByte((uint8)(0x68 << 1));
    if (!i2c_master_checkAck()) {
      os_printf("Error in writing to DS3231 on i2C\r\n");
      i2c_master_stop();
      return;
   }
    i2c_master_stop();
}


I am getting print

Error in writing to DS3231 on i2C

that means i2c_master_checkAck() is returnnig false.

May I request experts to please let me know why this code is not working.

[pratik]

I think the issue is with I2C bus initialization. You should comment out the code in I2C driver file which generates some cycles for clearing up the bus during initialization. This usually causes issues with some I2C devices...
Also, I2C devices are slow. Do not immediately access them after power-up. Wait for 5-10 ms at least.

Code: Select all

    // set data_cnt to max value
    for (i = 0; i < 28; i++) {
        i2c_master_setDC(1, 0);
        i2c_master_wait(5);   // sda 1, scl 0
        i2c_master_setDC(1, 1);
        i2c_master_wait(5);   // sda 1, scl 1
    }


[eriksl]

Actually, the problem is like this and when using I2c one will meet it quote a bit.

- esp8266 does NOT have hardware support for I2c (even though it's suggested)
- the "driver" code (software emulation) that comes with the SDK is awfully bad. It's slow, is not adhering to the standard and very flaky, it doesn't handle exceptions properly.

That's why I made my own, it's 10x as fast (can reach 800 kHz bus) and it's resilient to all sorts of abnormal conditions and recovers from them gracefully. Look for esp8266 io bridge on github.

[pratik]

That is great! If you want to, you can create a merge request on nonOS SDK code on GitHub/espressif.
I will recommend the I2C code internally and we will merge it to the SDK in the next release if approved internally.
Yes, the ESP8266 datasheet has some issues like that. There is not hardware support for features like I2C and PWM or IR. We are trying to make the ESP32 documentation better by avoid mistakes made on the ESP8266 platform.

[eriksl]

I'd gladly donate the existing code, but I am not going to actuallty integrate it into the SDK in any way, as long as large parts (not only the parts required for WiFi) of the SDK are closed source. Also there is still no proper direct hardware datasheet (list of every non-WiFi register with proper bit fields descriptions), no real memory map etc. I am not quite interested into the esp32, I think it's more for the "Arduino folks". The esp8266 suits me just fine. It only still lacks various items of documentation. Speaking of that, I think you still owe me some documentation about the timers on hardware level, you announced to produce

https://github.com/eriksl/esp8266-universal-io-bridge
https://github.com/eriksl/esp8266-unive ... ster/i2c.c
https://github.com/eriksl/esp8266-unive ... ster/i2c.h

One will need to add it's own i2c_error_format_string() function, as the supplied one depends heavily on my tiny string library that operates on strings in flash (see util.h). And I guess the calls to get_config need to be replaced by one's own version (or make it a parameter).

[pratik]

The WiFi and related peripheral registers are not declared publicly for good reason. Even if we allow management packets to be sent out using pkt_freedom APIs, I'm sure people will find a way to disrupt wireless traffic or hack other networks (not something we would like! Because that is easy to do with full control of the radio). That is the reason for the internal code being carefully closed source.
I myself do not have access to that, very few people do.
Sources that are useful are all free, such as LwIP port, mbedTLS, etc. Also, drivers for UART, timers, HSPI, etc are openly coded in driver library.

[eriksl]

I respect and understand the policy regarding the WiFi-related registers. The problem is all the other registers that are inadequately documented (or not at all).

I have e.g. serial communication using the UART working, after a lot of trial and error. What we need is a proper description of ALL (non-WiFi) peripheral registers, ALL the bits in them (not just a few of them, like it is now) and also a good description, not just three words. One could take a look at a datasheet from ATmel as an example. Example code is helpful, but it's not a replacement for proper documentation.

Area's that still lack proper or any documentation are imho:

- UART (how many UARTS are really implemented and describe the FIFO watermark/interrupt mechanism)
- memory map, as an official statement from Espressif what memory / I/O areas are mapped where, how the flash, iram, cache, dram, rom and I/O are mapped and how to control that mechanism (required to make e.g. an alternate boot loader)
- the timers, there are only examples now, we need proper documentation, for example for an alternate PWM implementation
- I haven't used it yet, but I am having the feeling that the SPI documentation is also way too sparse, many questions from users that really don't know where to start.

The "espconn" code, I can't imagine it contains any real low level WiFi related code, so it could be released into the public domain. That would allow the community to find bugs, optimisations and maybe also find a few spots where iram usage could be (further) reduced. Similarly the PWM "driver". I see quite a bit of complaints about it.

Iram usage is the most important, as it proves to be the only real factor that limits the size of the firmware. Every bit counts, as far as I'm concerned. I am now using ~ 300 kbytes of flash and it could grow to 4 mbytes without a problem (if proper flash chip is installed) if only the iram wouldn't fill up so quickly. My own code only uses a few hundred bytes of it (interrupt and high speed / frequency code), it's all SDK code that fills it up.

[pratik]

The espconn code is all open, including LwIP and mbedTLS. Only the PHY code is in the form of .a library files.
I will take the issue of registers into consideration as soon as possible.

[eriksl]

Hi Pratik,

I had a glance at the esp32 documentation lately and I was positively surprised. Much better documentation and much closer to professional documentation we're used to from other manufacturers. I guess that saves me from doing a "lecture" about wat we (I) am expecting.

Problem with espconn etc. is that it's delivered as a pre-compiled object. The relevant sources are supplied, as is required by it's licence, but it's not in a form that's readily compilable. The optimal solution would be to have a complete, fully contained directory, that one can place into it's own project (preferrably using a git submodule) and that one could simply build by calling "make".

I don't like the use pre-compiled binary blobs from third parties for various reasons, one of them being the chance of having ABI mismatches, compilation flags/options mismatches, compiler version mismatches, etc. For instance, to save the last few bytes of IRAM, I might one to compile using -Os instead of -O3 etc. Also, there might be functions declared IRAM that I will never use and will only use up precious IRAM space. I think it's fair though, that as soon as someone starts hacking there, there will be no support from Espressif.

And yes, a complete (!) overview/documentation of non-restricted registers would be very wellcome.

Thanks,
Erik.

[pratik]

You can pick the complete source from examples directory/LwIP project. It compiles just like any other project. You can access the makefiles and sources right away. No dependancy on any hidden stuff there. Same with mbedTLS (available as a complete different ZIP).
Anyway, we are trying to fix things with ESP32. A lot of the chapters are reviewed multiple times, including by me, before published. I'm glad it is turning out well.
ESP8266 is older than I am at Espressif, and I work remotely so not everything is in my control. I have access to the exact same sources that you folks do. Let's see what can be done with the ESP documentation, thanks for the feedback though. Lectures are better than not saying anything.