A problem with a bluepill and a DS3231SN

[Moriambar]

Hello guys and gals.

I have a really strange problem with the aforementioned components. Here's the datasheet for the DS3231 (from here: the rtc).

I hand soldered the rtc on an adapter board in order to experiment with it using a bluepill, and I hooked it up on the i2c bus.
I use the arduino IDE to program the thing and I wanted to try the RTCLib from adafruit. So I loaded up the basic sketch (the only change I made is the while loop and was suggested to me to circumvent some usb problems).

Code: [Select]

/* Example implementation of an alarm using DS3231
 *
 * VCC and GND of RTC should be connected to some power source
 * SDA, SCL of RTC should be connected to SDA, SCL of arduino
 * SQW should be connected to CLOCK_INTERRUPT_PIN
 * CLOCK_INTERRUPT_PIN needs to work with interrupts
 */

#include <RTClib.h>
#include <Wire.h>

RTC_DS3231 rtc;

// the pin that is connected to SQW
#define CLOCK_INTERRUPT_PIN 26

void setup() {
    Serial.begin(9600);
while(!Serial)
  delay(1);
    // initializing the rtc
    if(!rtc.begin()) {
        Serial.println("Couldn't find RTC!");
        Serial.flush();
        abort();
    }
    
    if(rtc.lostPower()) {
        // this will adjust to the date and time at compilation
        rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
    }
    
    //we don't need the 32K Pin, so disable it
    rtc.disable32K();
    
    // Making it so, that the alarm will trigger an interrupt
    pinMode(CLOCK_INTERRUPT_PIN, INPUT_PULLUP);
    attachInterrupt(digitalPinToInterrupt(CLOCK_INTERRUPT_PIN), onAlarm, FALLING);
    
    // set alarm 1, 2 flag to false (so alarm 1, 2 didn't happen so far)
    // if not done, this easily leads to problems, as both register aren't reset on reboot/recompile
    rtc.clearAlarm(1);
    rtc.clearAlarm(2);
    
    // stop oscillating signals at SQW Pin
    // otherwise setAlarm1 will fail
    rtc.writeSqwPinMode(DS3231_OFF);
    
    // turn off alarm 2 (in case it isn't off already)
    // again, this isn't done at reboot, so a previously set alarm could easily go overlooked
    rtc.disableAlarm(2);
    
    // schedule an alarm 10 seconds in the future
    if(!rtc.setAlarm1(
            rtc.now() + TimeSpan(10),
            DS3231_A1_Second // this mode triggers the alarm when the seconds match. See Doxygen for other options
    )) {
        Serial.println("Error, alarm wasn't set!");
    }else {
        Serial.println("Alarm will happen in 10 seconds!");  
    }
}

void loop() {
    // print current time
    char date[10] = "hh:mm:ss";
    rtc.now().toString(date);
    Serial.print(date);
    // the value at SQW-Pin (because of pullup 1 means no alarm)
    Serial.print(" SQW: ");
    Serial.print(digitalRead(CLOCK_INTERRUPT_PIN));
    // whether a alarm happened happened
    Serial.print(" Alarm1: ");
    Serial.print(rtc.alarmFired(1));
    // Serial.print(" Alarm2: ");
    // Serial.println(rtc.alarmFired(2));
    // control register values (see [url]https://datasheets.maximintegrated.com/en/ds/DS3231.pdf[/url] page 13)
    // Serial.print(" Control: 0b");
    // Serial.println(read_i2c_register(DS3231_ADDRESS, DS3231_CONTROL), BIN);
    
    // resetting SQW and alarm 1 flag
    // using setAlarm1, the next alarm could now be configurated
    if(rtc.alarmFired(1)) {
        rtc.clearAlarm(1);
        Serial.println("Alarm cleared");
    }
    
    delay(2000);
}

void onAlarm() {
    Serial.println("Alarm occured!");
}

Please do mind that the bluepill has worked fine so far so I have no reason to suspect it not working.
The problem is that upon starting the program I get the "Couldn't find RTC!" message.

I analyzed the i2c bus activity and I clearly see that the pill correctly tries to write to address 0x68 during the RTC begin function, but the message ends with a NAK.

I then manually checked all of the connections and soldering and can confirm (with two multimeters, via buzzing) that:

• pins 5 to 13 are connected to GND
• pin 2 is connected to VCC
• Pin 16 is connected to SCL
• pin 15 is connected to SDA
• every pin on the chip buzzes with the corresponding pin on the breakout board

I also have confirmed that pin 4 goes to VCC without pulling it up (as expected).

I have no activity on pin 1.

I seriously don't know what else to check. Is my rtc defective? Am I so unlucky to have 2 defective components in the same week? (the other one was an eeprom).

thanks for anyone who's willing to help!

[tooki]

Do you have pull-up resistors on the SDA and SCL buses?

[Manul]

Note, that pin 1 (32khz out) is open drain, so you need pullup resistor to "see activity". Also you haven't mentioned pullup resistors for I2C. Do you have them? What value?

[Moriambar]

yes sorry guys, I have 10k pullups and succeeded talking to the eeprom using the same bus (no conflict, eeprom's address is 0x50).

One extra note: is it possible to see clock and sda activity via the logic analyzer without any pullups?

thanks

[Manul]

yes sorry guys, I have 10k pullups and succeeded talking to the eeprom using the same bus (no conflict, eeprom's address is 0x50).

So you have pullups, but DS3231 still does not work? Put lower pullups, try 2.2K. Also make sure you have bypass capacitor near DS3231.

One extra note: is it possible to see clock and sda activity via the logic analyzer without any pullups?

Pullup resistors should be present somewhere on the bus (their location is not really important). Without them it is just open drain lines, so no, analyzer will not see it. Note that some ICs may have internal I2C pullups. Also some people have "success" using programmable pullups on MCUs, but that is usually much too high value for proper use of I2C.

[Moriambar]

So you have pullups, but DS3231 still does not work? Put lower pullups, try 2.2K. Also make sure you have bypass capacitor near DS3231.

First of all thanks. I'll try. I was just using what was "recommended" for the eeprom. I'll try 2k2 and give feedback in a couple of hours I think

Pullup resistors should be present somewhere on the bus (their location is not really important). Without them it is just open drain lines, so no, analyzer will not see it. Note that some ICs may have internal I2C pullups. Also some people have "success" using programmable pullups on MCUs, but that is usually much too high value for proper use of I2C.

Cool, thanks, that's nice to know. I never used internal pullups, so at least I did one thing right!

[Moriambar]

ok there's definitely something sketchy going on:

• 10k pullup -> nothing works
• 2k2 pullup and only the pill -> nothing works
• 2k2 pullup, pill AND logic analyzer attached -> things work

I don't know what to say. maybe the 3.3v regulator on the pill is not working properly? (to have serial I have to power it over usb)
Is there anything else I can check? I cannot consider this solved…

[Manul]

Do you have properly placed bypass capacitor on DS3231 Vcc?

[Moriambar]

Do you have properly placed bypass capacitor on DS3231 Vcc?

Yes, I have 0.1uF from his VCC pin to GND

[Manul]

Do you mind sharing a picture of your circuit? If things act sketchy, it might be something about the layout.

[Moriambar]

Do you mind sharing a picture of your circuit? If things act sketchy, it might be something about the layout.

here it is with the 10k resistors.
The extra chip is the 24LS512 eeprom removing it does nothing so I left it in. It seems a mess but in order to connect all of the pins to ground I had to get creative.

cheers!

[Manul]

Well, could be bypass capacitor issue, too long wires or some dodgy connection. I would recommend that you solder bypass capacitor directly between DS3231 pin 2 and pin 13 (and keep legs short). Maybe you just have too long wires and high capacitance on the bus. Try lowering pullup down to 1K.

[retiredfeline]

There are several example programs in the RTC library, have you tried running those to read and set the time before you get into alarms and interrupts?

[Moriambar]

There are several example programs in the RTC library, have you tried running those to read and set the time before you get into alarms and interrupts?

Hi, no but it's "rtc.begin" that fails. Nothing about the alarms

[Moriambar]

Well, could be bypass capacitor issue, too long wires or some dodgy connection. I would recommend that you solder bypass capacitor directly between DS3231 pin 2 and pin 13 (and keep legs short). Maybe you just have too long wires and high capacitance on the bus. Try lowering pullup down to 1K.

So I tried to use 1k pullups and the clock works! The problem is that the eeprom doesn't anymore. But I'll try to manage that separately (I made a custom driver, could be it).
Thank you

[cemelec]

By Bluepill I assume you are using the STM32F103xx

Some years ago I had an awful lot of problems with that chip trying to use I2C (for RTC and barometric sensors, + others)

Turns out there was a silicon problem with the chip itself; Google "STM32F103 silicon errata" and it should take you to somewhere on the ST website. The relevant document suggests various workarounds, but its ugly.

Maybe this is not your problem at all, maybe its been fixed, but I lost many hours sorting this out.

[Moriambar]

By Bluepill I assume you are using the STM32F103xx

Some years ago I had an awful lot of problems with that chip trying to use I2C (for RTC and barometric sensors, + others)

Turns out there was a silicon problem with the chip itself; Google "STM32F103 silicon errata" and it should take you to somewhere on the ST website. The relevant document suggests various workarounds, but its ugly.

Maybe this is not your problem at all, maybe its been fixed, but I lost many hours sorting this out.

Thanks my blue pill is indeed old, but with 1k pull-ups (and a software fix for the eeprom) everything seem to work correctly. I'll take a look into the documents you suggests anyhow. Thanks

[tooki]

A few observations:
1. it shouldn’t be necessary to have such strong pull-ups. I’ve used the DS3231 many times and have never had to use anything stronger than 10K. The I2C standard has formulas for calculating maximum and minimum pull-up values.
2. Your pull-ups (as shown on the breadboard) are willy-nilly, one connected here, another connected there… give them a nice clean reference.
3. I2C doesn’t like being run in tight parallel formation. Instead of using the bus bars, try using jumper wires, either in a star or daisy-chain topology. You can also run I2C as twisted pairs, with each line twisted with ground. (On runs >10cm, the I2C standard suggests running VCC and ground between SDA and SCL, or at least ground. So running them on a 20cm breadboard bus is not a good idea, and your giant blue/orange I2C loop alone already violates the recommendations.)
4. The i2cscanner sketch can be handy for tracking down issues like this. It just continuously spits out a list of the addresses of all I2C devices found. You can then monkey around with the bus and see what causes them to work.
5. Don’t rule out the possibility (especially with cheap breadboards and jumpers) that it’s not the value of the pull-ups that make it work or fail, but rather the physical manipulation of the circuit that has a bad connection somewhere.

[Moriambar]

A few observations:
1. it shouldn’t be necessary to have such strong pull-ups. I’ve used the DS3231 many times and have never had to use anything stronger than 10K. The I2C standard has formulas for calculating maximum and minimum pull-up values.
2. Your pull-ups (as shown on the breadboard) are willy-nilly, one connected here, another connected there… give them a nice clean reference.
3. I2C doesn’t like being run in tight parallel formation. Instead of using the bus bars, try using jumper wires, either in a star or daisy-chain topology. You can also run I2C as twisted pairs, with each line twisted with ground. (On runs >10cm, the I2C standard suggests running VCC and ground between SDA and SCL, or at least ground. So running them on a 20cm breadboard bus is not a good idea, and your giant blue/orange I2C loop alone already violates the recommendations.)
4. The i2cscanner sketch can be handy for tracking down issues like this. It just continuously spits out a list of the addresses of all I2C devices found. You can then monkey around with the bus and see what causes them to work.
5. Don’t rule out the possibility (especially with cheap breadboards and jumpers) that it’s not the value of the pull-ups that make it work or fail, but rather the physical manipulation of the circuit that has a bad connection somewhere.

You got it, it was the busbar configuration, probably not a high quality breadboard too. nevertheless now I daisy chained and everything works with  10k pullups

[tooki]

Thanks for the report, glad to hear it helped!

Chances are it was crosstalk between the lines. I used my LCR meter to measure the capacitance of a bus bar pair on a breadboard just like that, and it was about 20pF, well below the 400pF limit. So I’d say your breadboard is vindicated. :p

[Moriambar]

Thanks for the report, glad to hear it helped!

Chances are it was crosstalk between the lines. I used my LCR meter to measure the capacitance of a bus bar pair on a breadboard just like that, and it was about 20pF, well below the 400pF limit. So I’d say your breadboard is vindicated. :p

maybe bad topology or crosstalk with the usb cable perhaps…

[BreakingOhmsLaw]

Beware: Some bluepill clones have different clock speed behaviour. Big trap. I have a bunch that did not work with a bit-banged 1-wire protocol. Turned out it was running at twice the speed compared to other boards. Only found this out when i hooked a scope to the 1-wire bus and saw that the timing was all wrong.
Never bothered to find the cause (not worth the time given the price) probably due to a badly implemented STM32 clone.

[Moriambar]

Beware: Some bluepill clones have different clock speed behaviour. Big trap. I have a bunch that did not work with a bit-banged 1-wire protocol. Turned out it was running at twice the speed compared to other boards. Only found this out when i hooked a scope to the 1-wire bus and saw that the timing was all wrong.
Never bothered to find the cause (not worth the time given the price) probably due to a badly implemented STM32 clone.

Thanks, but the SCL line was at 100kHz, so I'm fine in that respect

[DavidAlfa]

Thanks for the report, glad to hear it helped!

Chances are it was crosstalk between the lines. I used my LCR meter to measure the capacitance of a bus bar pair on a breadboard just like that, and it was about 20pF, well below the 400pF limit. So I’d say your breadboard is vindicated. :p

That's why I rarely use breadboards! They cause a lot of trouble, I use cheap drilled prototype PCBs when possible.