Page 1 of 2

NUCLEO-F411 I2C ack failure

Posted: Tue Oct 20, 2015 9:43 am
by micsel
Hello to everybody. First of all I'd like to congratulate for the great work that you're doing developing this useful OS.

I'm writing here because I'm not able to make I2C bus work in my project. I need to make my nucleo-f411 board communicate with a ds1307 RTC.

The electrical connection is done using a 100 Ohm resistor on SDA and on SDL placed between the uC and the RTC and a 4,7KOhm resistor placed between sda and VCC and another one between SCL and VCC. The VCC is 5V. This is the voltage of RTC supply. I know that it's not the best thing to do to put a 5V signal as input of a 3.3V supplied uC but these pins should be 5V tolerant.

The version of ChibiOS that I'm using is the 3.0.1. The problem that i get is the following: if in the function "rtc_init()" i execute the i2C_start() before the pin configuration as alternate function, when I try to execute the i2cMasterTransmitTimeout I get, as return value, MSG_TIMEOUT. Otherwise if I execute the I2C_start() after the pin configuration as alternate function i get MSG_RESET and the i2cGetErrors gives me a return value of 4 that should correspond to an ACK_FAILURE.

The code that I'm trying to execute is more or less the following one (I reported only that part that uses I2c because the whole code is extended and distributed on more modules):

Code: Select all

#define RTC_SDA_PORT        GPIOB
#define RTC_SDA_PIN           6

#define RTC_SCL_PORT        GPIOB
#define RTC_SCL_PIN           7

#define RTC_I2CD                I2CD1
#define DS1307_ADDRESS     0x68

#define TMO                        MS2ST(20)

typedef struct{
    uint8_t secReg;
    uint8_t minReg;
    uint8_t hourReg;
    uint8_t dayOfWeekReg;
    uint8_t dayReg;
    uint8_t monthReg;
    uint8_t yearReg;
    uint8_t ctrlReg;
} rtc_rawDataRx_t;

typedef struct{
    uint8_t startRegister;
    uint8_t secReg;
    uint8_t minReg;
    uint8_t hourReg;
    uint8_t dayOfWeekReg;
    uint8_t dayReg;
    uint8_t monthReg;
    uint8_t yearReg;
    uint8_t ctrlReg;
} rtc_rawDataTx_t;

typedef struct{
    rtc_rawDataRx_t rawDataRx;
    rtc_rawDataTx_t rawDataTx;
    rtc_data_t    dataTx;
    rtc_data_t    dataRx;
    bool isRunning;
    bool isInitiated;
    msg_t status;
    bool initFlag;
}rtc_t;

static const I2CConfig i2cfg1 =
        { OPMODE_I2C, 400000, FAST_DUTY_CYCLE_2 };

rtc_t rtc;

void rtc_init (void)
{
    palSetPadMode(RTC_SDA_PORT, RTC_SDA_PIN, PAL_MODE_OUTPUT_OPENDRAIN);
    palSetPadMode(RTC_SCL_PORT, RTC_SCL_PIN, PAL_MODE_OUTPUT_OPENDRAIN);
    palSetPadMode(RTC_SDA_PORT, RTC_SDA_PIN, PAL_MODE_ALTERNATE(4));
    palSetPadMode(RTC_SCL_PORT, RTC_SCL_PIN, PAL_MODE_ALTERNATE(4));
    chThdSleepMilliseconds (200);
    i2cStart(&RTC_I2CD, &i2cfg1);
    chThdSleepMilliseconds (200);
    rtc.initFlag = true;
}

rtc_rawDataRx_t rtc_getRtcData (void)
{
    i2cflags_t error;
    uint8_t txbuf[1];
    txbuf[0]= 0x00;
    i2cAcquireBus(&RTC_I2CD);
    rtc.status = i2cMasterTransmitTimeout(&RTC_I2CD, DS1307_ADDRESS, txbuf, 1, (uint8_t*)(&(rtc.rawDataRx)), (sizeof(rtc_rawDataRx_t))/8, TMO);
    i2cReleaseBus(&RTC_I2CD);
    if (rtc.status != MSG_OK)
    {
        error = i2cGetErrors (&RTC_I2CD);
    }
    return rtc.rawDataRx;
}

void main (void)
{
    halInit();
    chSysInit();
    rtc_init();
    rtc_getRtcData();
}

Re: NUCLEO-F411 I2C ack failure

Posted: Tue Oct 20, 2015 12:03 pm
by Giovanni
Hi,

Are debug options enabled in chconf.h? (assertions, checks, state checker) If not try to enable them and see if something is caught.

Details about debug options are here: http://www.chibios.org/dokuwiki/doku.ph ... ebug_guide

Also make sure to read this article regarding I2C: http://wiki.chibios.org/dokuwiki/doku.p ... e_shooting

I don't know for sure if putting 5V there is OK, you should double check that.

Giovanni

Re: NUCLEO-F411 I2C ack failure

Posted: Tue Oct 20, 2015 12:49 pm
by micsel
Thank you for your reply.

Putting 5V should not cause problems because the pins that I'm using are marked as 5V tolerant on F411 datasheet. However this connection is just temporary because the hardware to realize a level shifter hasn't still arrived. In the final version i will use a level shifter to not stress uC input circuitry.

I've read the troubleshooting about I2C that you linked me and the only thing that I haven't done yet is to try using the "PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN" configuration in my last tests (i did it in previous ones but i don't remember if other bugs that I found in my code were already fixed, so I will try again hoping in a better luck). As you can see from the code that I previously posted i set those pins as opendrain and as AF in two different operations and maybe this causes the problems.

Regarding debug options I've no option enabled. I will try if the pin configuration solution won't work.

In the meanwhile can you tell me if you see some mistakes in the code (even if I'm pretty sure that it's correct).

I'll write some update about my progresses as soon as I've got some news.

Re: NUCLEO-F411 I2C ack failure

Posted: Tue Oct 20, 2015 1:08 pm
by micsel
While reading the articles reported in I2C troubleshooting I started to think that the slave device may not support the fast mode. In fact, in DS1307 datasheet is reported that the maximum SCL frequency supported is 100 KHz.

During my tests I tried to slow down clock frequency using a 100 KHz value and a 4KHz value but i didn't change the I2C mode leaving FAST_DUTY_CYCLE_2.

As soon as I can I'll try to use the right configuration and I'll tell you if it works but I think that we've found the real problem.

I've seen that in i2c_lld there are several check on duty cycle mode and frequency couples. Can you please suggest me a correct i2c configuration to use a 10KHz or 100 KHz mode? Should the following one be correct: {OPMODE_I2C, 10000, STD_DUTY_CYCLE}? Can I use intermediate values between 10 KHz and 100 KHz ? Even if they're not standard values, the master should generate the clock, so it should be able to generate the desired clock even if not standard, am I right?

Re: NUCLEO-F411 I2C ack failure

Posted: Tue Oct 20, 2015 8:56 pm
by micsel
I tried to use the pin configuration reported (AF | OPENDRAIN) and the I2C standard mode configuration (both {100000, STD_DUTY_CYCLE} and {10000, STD_DUTY_CYCLE}) but I still get the ack failure error.

I also tried to enable debug checks and assertions but everything works correctly (except for the ack failure).

I don't know anymore which error can cause this problem. Really need help.

Re: NUCLEO-F411 I2C ack failure

Posted: Tue Oct 20, 2015 11:10 pm
by Giovanni
Hard to give advice..

Do you have a logic analyzer? also check that the address is right, the I2C driver address is NOT the first byte, it is the 7 bits value aligned to right.

Giovanni

Re: NUCLEO-F411 I2C ack failure

Posted: Wed Oct 21, 2015 6:18 am
by micsel
I will try acquiring the signal through an oscilloscope because I don't have a logic analyzer.

Re: NUCLEO-F411 I2C ack failure

Posted: Wed Oct 21, 2015 5:27 pm
by Jacon
Giovanni wrote:Hi,
I don't know for sure if putting 5V there is OK, you should double check that.

There's special item in latest Errata.pdf
(http://goo.gl/jJ9rfn)
on 5V & I2C's:

2.3.5 Both SDA and SCL maximum rise time (tr) violated when VDD_I2C bus
higher than ((VDD+0.3) / 0.7) V

It's worth reading, I suppose (especially when one's MCU Vdd is below 3.3V)...

Re: NUCLEO-F411 I2C ack failure

Posted: Thu Oct 22, 2015 7:59 am
by micsel
Jacon thank you very much for posting this document. I carefully read it. I didn't imagine that there could be such problems. But fortunately my system is supplied by a 3.3V line. In consequence of that, as reported in the errata, the maximum admissible voltage on SDA and SCL pins is 5.14 V. I measured it yesterday and it is at 4.9 V. I'll try to see what is happening on those lines using an oscilloscope as soon as possible to be sure that my uC puts his signals out and that the waves are clean enough. If I'll be able to verify that I will confirm my suspect that the peripheral has something wrong that make it not properly working.

Writing on google "DS1307 not responding" I found many posts of people having problems while trying to communicate with this device. For example I've read that a battery voltage that is out from the requested range can cause communication problems (I tested mine one and it seems to be correct), or someone else reporting a broken crystal oscillator mounted (I bought the DS1307 already mounted on a board that includes the oscillator, a battery and an eeprom). I hope to be able to solve this problem and to share my solution.

Re: NUCLEO-F411 I2C ack failure

Posted: Sat Oct 24, 2015 10:49 pm
by rew
Really the DS1307 is a "reliable" chip, but it is often the one and only chip people try on I2C, and therefore often run into communications problems that are not the fault of the DS1307...