Bootloading Error with Sketch using DS3232RTC on ESP8266

Projects Programming
1

Hi All,

I've been working on adding a DS3231 RTC to a project that's running Arduino on an ESP8266 (I will add Wifi later). I've had success with the DS1307 but I wanted to make use of the alarm functions that the DS3231 provide.

I've been able to set and read the time using Adafruit's RTClib but I've moved on to "DS3232RTC" library provided by: GitHub - JChristensen/DS3232RTC: Arduino Library for Maxim Integrated DS3232 and DS3231 Real-Time Clocks since a lot of folks seem to use that one for setting and handling the alarms (the Adafruit library doesn't mention any alarm functions).

My Hardware:
ESP8266 running Arduino 1.6.12
DS3231 SDA > pin 4 on ESP
DS3231 SCL > pin 5 on ESP
DS3231 SQW > 10K pullup resistor to VCC & pin 14 on ESP

My Issue: the sketch below complies and uploads but immediately throws the following errors in the Monitor:

"ets Jan 8 2013,rst cause:4, boot mode:(1,7)

wdt reset

ets Jan 8 2013,rst cause:4, boot mode:(1,7)

wdt reset"

Then nothing. I can always go back and load different sketches and they all compile and run successfully so I don't think there's a wiring issue. I've also deleted and redownloaded the DS3232RTC library to make sure my copy wasn't corrupted. I've been googling those error messages and a lot of the solutions I'm finding relate to wiring and insufficient power issues. But if I'm able to load different sketches with the same wiring/powering setup, that shouldn't be an issue, correct? I'm out of ideas.

Has anyone run into this issue before? Is it related to my other libraries? It must be related to my sketch but I can't figure out where exactly. Any help is greatly appreciated!!

#include <Time.h>
#include <TimeLib.h>
#include <Wire.h>
#include <DS3232RTC.h>


volatile boolean alarmFlag = false; 

void setup() {
  Serial.begin(115200);
  delay (1000);
  Serial.println("initializing DS3231");
  setSyncProvider(RTC.get);
  RTC.squareWave(SQWAVE_NONE);
  RTC.alarmInterrupt(ALARM_1, false);
  RTC.alarmInterrupt(ALARM_2, false);
  RTC.setAlarm(ALM1_MATCH_SECONDS, 20, 0, 0, 2);
  RTC.alarmInterrupt(ALARM_1, true);
  pinMode(14, INPUT);
  attachInterrupt(14, alarmISR, FALLING); 
}

void loop() {
  time_t currentTime;
  currentTime = RTC.get();
  Serial.println(currentTime);
  if (alarmFlag == true) {
    Serial.println("the 20 second alarm just went off!");
    alarmFlag = false;
  }
delay (1000);
}

void alarmISR() {
  alarmFlag = true;
}
2 
  attachInterrupt(14, alarmISR, FALLING);

Does the ESP8266 really have 15 (or more) external interrupts?

3

Hi PaulS,

Yes, according to the Arduino Documentation for the ESP8266:

Pin interrupts are supported through attachInterrupt, detachInterrupt functions. Interrupts may be attached to any GPIO pin, except GPIO16. Standard Arduino interrupt types are supported: CHANGE, RISING, FALLING.

https://arduino-esp8266.readthedocs.io/en/latest/reference.html#digital-io

So I don't think that's the issue. Also, I have another project that uses an interrupt on that pin which is why I stuck with pin 14.

4

Unlike other Arduinos, the ESP8266 initializes the watchdog timer by default. So, you need to make sure that you pet the dog often enough. Petting doesn't happen during delay().

So, stop using delay(). You can achieve the same results using the blink without delay technique.

That may not be your real problem, but it is one that you can eliminate quite easily.

5

Thanks for the quick replies! I've removed both Delay() statements but alas, I'm still receiving the same error messages. :confused:

6

Any other thoughts?

7

dsoccer31:
Any other thoughts?

I'd add (a lot) more Serial.print() statements, to see which statement triggers the reset.

8

Try using D14 instead of 14. Do your other test sketches actually read pin 14?

9

PaulS:
Petting doesn't happen during delay().

So, stop using delay(). You can achieve the same results using the blink without delay technique.

That may not be your real problem, but it is one that you can eliminate quite easily.

That's not correct: Calling 'delay' or 'yield' resets the WDT and gives CPU time to the TCP/IP stack and other important stuff that runs in the background.

Pieter

10

PaulS:
I'd add (a lot) more Serial.print() statements, to see which statement triggers the reset.

I'll definitely give this a shot but given that my very first serial.println in setup() doesn't even run, something tells me somethings not right at loading time. Like it it compiles in the IDE but doesn't compile for the MCU.

void setup() {
  Serial.begin(115200);
  delay (1000);
  Serial.println("initializing DS3231"); // if never even gets to here...
11

aarg:
Try using D14 instead of 14. Do your other test sketches actually read pin 14?

Thanks but on the ESP8266, pin 14 is a digital pin. And yes, I can successfully read from Pin 14 using my other sketches.

Have you guys used the DS3232RTC and Time libraries before? I'm wondering now if there's a compiler issue with the Time library since it's been migrated to Github and updated. I've been reading through the issues and it seems like some folks have issues with their compiler adding different Time.h libraries.

12

dsoccer31:
Thanks but on the ESP8266, pin 14 is a digital pin. And yes, I can successfully read from Pin 14 using my other sketches.

Have you guys used the DS3232RTC and Time libraries before? I'm wondering now if there's a compiler issue with the Time library since it's been migrated to Github and updated. I've been reading through the issues and it seems like some folks have issues with their compiler adding different Time.h libraries.

I know, but recently I had the issue of a pin not responding on an ESP8266 module. The code compiled fine but the pin 4 didn't respond. I intuitively tried using "D4" in place of "4" in all my pin commands and it suddenly worked perfectly. I know that it seems strange, but it's what happened, so I thought I should suggest it. Edit - not 4, it was a different number, but you get the idea... it was actually the pin for the on board LED.

I made absolutely no other changes to the code besides that change.

13

I know that it seems strange, but it's what happened, so I thought I should suggest it

Oh man, talk about strange! I was really beating my head against the wall tonight trying to figure this out so I decided to (tediously) add my code to a new sketch line by line. For whatever reason, the sketch now loads. Literally not a single line of code or wiring changed! I really can't explain it.

The only thing I can remember doing is - in an act of desperation early today - I renamed my local Time.cpp file (for the Time Library) to TimeLib.cpp and then back again. I guess it's possible that that change could have had some affect but I don't know why. I'm just glad it's working. Now I'm up and running with this library and can finally get back to my project. Whew. Thanks for your time and thoughts @aarg. :slight_smile: