esp8266: RTC support + linker script update

[atx]

Note that the internal RTC has extreme drift (~1 second over 1 minute), so I am not really sure if the last commit is even worth merging.

[pfalcon]

Note that the internal RTC has extreme drift (~1 second over 1 minute)

Is there any reference for this issue, or is this personal experience? (I mean, there should be some means to calibrate it if it's really "RTC").

[blmorris]

It doesn't appear to be 'real' RTC, but rather an internal low-speed oscillator running at ~32kHz.
Note that I don't have any direct experience with the ESP8266, but just today I did some research on RTC hardware for the various uPy ports as part of #1239

[atx]

Ok, is it really "flash sector size"?

Fixed, I guess that could have been misleading.

Is there any reference for this issue, or is this personal experience?

There does not seem to be much about the internal RTC anywhere. This rough figure is what I got after leaving the module running for about an hour. According to the datasheet, you can connect a 32.768kHz clock to the EXT_LFC pin, the only problem being that it does not really mention which pin this actually is.

(I mean, there should be some means to calibrate it if it's really "RTC").

As @blmorris says, it looks more like a standard timer than a real RTC, the main difference being that it runs even when in deep sleep.

[coveralls]

Coverage decreased (-0.0%) to 93.48% when pulling 7b4de49 on atalax:esp into a7c02c4 on micropython:master.

[dpgeorge]

the main difference being that it runs even when in deep sleep.

I guess then it's useful to be able to set the "time" so that you can wake up when wanted.

[coveralls]

Coverage decreased (-0.0%) to 93.48% when pulling 8afa6aa on atalax:esp into a7c02c4 on micropython:master.

[chrismas9]

from http://www.esp8266.com/viewtopic.php?p=1563

"Espressif has stated on their BBS that the EXT_LF clock feature doesn't work. It was deleted from their Chinese datasheet but they missed the paragraph in the English one. It is now deleted in the current English version. So nothing is being hidden, it just didn't work right."

According to the pin list here: http://esp8266.ru/downloads/esp8266-doc/#wpfb-cat-1 GPIO5 alternate function 2 CLK_RTC is an output only.

So the RTC is really only useful for waking up from deep sleep at an approximate time. It would help to do quick calibrate from the 26MHz before going into deep sleep but there is no point in doing it over a long period as the RC osc will drift with temperature.

[blmorris]

For what it's worth, the internal low speed clock on the ESP8266 isn't some weird anomaly or defect; it is common for microcontrollers to have an internal low speed (typically 32kHz) RC relaxation oscillator to run an independent watchdog timer or to provide a signal to wake up from a low-power sleep mode. The STM32F4xx series processors have this as well; we just don't use it because the pyboard has a much more accurate external 32.768kHz crystal. The internal oscillator is typically provided to allow for reduced-cost designs by omitting a crystal when high accuracy is not critical. The internal oscillator will be relatively low accuracy; as far as I can tell nobody has figured out how to fabricate an accurate quartz watch crystal on a silicon wafer - but the way that MEMS technology is advancing, who knows? ;)
Just my 2 cents, but I see no reason not to support it in the ESP8266 port; just maybe call it 'LSI' for 'Low Speed Internal' rather than 'RTC'.

[pfalcon]

I'll try do add my comments on the discussion above if got time, but general answer to:

Note that the internal RTC has extreme drift (~1 second over 1 minute), so I am not really sure if the last commit is even worth merging.

is - Yes, is the code is clean, it's worth adding, so others could start from that and move further, instead of doing it again (just to discover same issues, instead of figuring how to resolve them).

Other out-of-band note: I see you forked radare2. Dunno if that's related to esp8266 hacking or not, but I'd like to make sure you know about https://github.com/pfalcon/ScratchABit . I started that after once again confirming that radare2 isn't going to work for me. And yes, it's started because of esp8266 hacking (and some other hacking projects I spotted recently).

[atx]

I also realized, that this "fuzzy" RTC can be useful in battery-powered applications to at least decrease the frequency with which one has to connect to Wi-Fi and sync with a server.

It would help to do quick calibrate from the 26MHz before going into deep sleep...

This might actually be what the magical system_rtc_clock_cali_proc() does.

I see you forked radare2...

Yes, I wanted to add support for Xtensa so I can have a better look at the ROM BLOB

I'd like to make sure you know about https://github.com/pfalcon/ScratchABit

Hm, this looks interesting. Quickly testing it out, it even looks like this plugin works out of the box. I am definitely going to take a look at it later :)

[pfalcon]

Hm, this looks interesting. Quickly testing it out, it even looks like this plugin works out of the box. I am definitely going to take a look at it later :)

Yes, that's how initial code of scratchabit was written - taking ida-xtensa, and then writing code around it until I got disassembly. Couple of latest patches to ida-xtensa are from me and tested against scratchabit, and I have more in queue. So, scratchabit needs you not less than micropython ;-). But yeah, let's move this discussion to scratchabit's own tracker if anything.

[dpgeorge]

@pfalcon are you happy if I merge this?

[pfalcon]

I didn't have time to review it in detail, but if you did, please merge.

[dpgeorge]

Merged in 800d5cd, 1db4253, b479319 and 103d12a.

Thanks @atalax for this, especially factoring out timeutils to lib/. That's something that needed doing.

Note that in 4e7dc97 I added module weak link time to utime, so now you can do import time and it'll work (also you can override time module if you have time.py in your path).

On my esp dev board the time.localtime() and time.time() functions crash the MCU. They both call pyb_rtc_get_us_since_2000... any ideas?

[atx]

Oops, pushed to the wrong branch. Let me close this.

On my esp dev board the time.localtime() and time.time() functions crash the MCU.

Hmm, strange. Try building with 3d8fb90 and UART_OS=0, should print address and error code.

[dpgeorge]

Hmm, strange.

It's probably because I was using an outdated esp_iot_sdk version.

[coveralls]

Coverage decreased (-0.01%) to 93.82% when pulling 8b81eb1 on atalax:esp into 4e7dc97 on micropython:master.