cpu/esp32: replace RTC implementation by RTT implementation

[gschorcht]

Contribution description

This PR replaces the RTC implementation with an RTT implementation that uses the RTC hardware timer of the ESP32. The RTC implementation used instead is the RTT based RTC implementation provided by the rtt_rtc module.

Although the RTC hardware module of the ESP32 is called an RTC, it is a Real Time Timer (RTT) rather than a Real Timer Clock. Therefore, the former RTC peripheral driver implementation is replaced by an RTT periphal driver implementation.

Note: An RTT/RTC alarm is not preserved during reboot or deep-sleep.

Testing procedure

tests/periph_rtc and tests/periph_rtc should work

make BOARD=esp32-wroom-32 -C tests/periph_rtt flash test

make BOARD=esp32-wroom-32 -C tests/periph_rtc flash test

Furthermore, use tests/periph_pm can be used to test that the RTT and RTC are retained in sleep modes and during reboot.

CFLAGS='-DESP_PM_WUP_PINS=GPIO0 -DESP_PM_WUP_LEVEL=ESP_EXT1_WAKEUP_ALL_LOW' \
USEMODULE='shell_commands rtt_cmd' \
make BOARD=esp32-wroom-32 -C tests/periph_pm flash term

> rtc settime 2020-03-29 16:17:40
> rtc gettime
2020-03-29 16:17:43
> reboot
...
> rtc gettime
2020-03-29 16:17:49
> set 0
CPU will enter power mode 0.

Press BTN0

...
> rtc gettime
2020-03-29 16:18:01

Issues/PRs references

[benpicco]

Could it be that the toolchain on Murdock was upgraded and now compile/tests/libc_newlib/esp32-wrover-kit:gnu is always failing?

Do you have a fix hidden in here? 😉
I think I saw this fail on the same test a little earlier, now it isn't failing that test.

[gschorcht]

Could it be that the toolchain on Murdock was upgraded and now compile/tests/libc_newlib/esp32-wrover-kit:gnu is always failing?

Do you have a fix hidden in here?
I think I saw this fail on the same test a little earlier, now it isn't failing that test.

I don't know, I saw this problem too. Maybe @kaspar030 updated the toolchain only on one worker and if tests/libc_newlib compilation lands on that worker, it will fail 😟 :

The problem is not really clear to me, but I can also see it locally. The test complains that the addresses of printf and iprintf are the same.

   text	   data	    bss	    dec	    hex	filename
  40646	   3384	   6400	  50430	   c4fe	/home/gs/src/RIOT-Xtensa-ESP.working/tests/libc_newlib/bin/esp32-wroom-32/tests_libc_newlib.elf
Test: comparing addresses of 'printf' and 'iprintf' symbols
[FAILED] '400d0334' != '400d0334' is False

According to the comment in test's README, these symbols should address the same code in newlibc-nano.

OK, I forgot to add newlib_nano as module when providing the new toolchain. But even if I use

USEMODULE=newlib_nano make BOARD=esp32-wroom-32 -C tests/libc_newlib

the linker test fails.

[gschorcht]

OK, I forgot to add newlib_nano as module when providing the new toolchain. But even if I use

USEMODULE=newlib_nano make BOARD=esp32-wroom-32 -C tests/libc_newlib

the linker test fails.

Forget it, it's too late today ... With

USEMODULE=newlib_nano make BOARD=esp32-wroom-32 -C tests/libc_newlib

the test works. The output seems too similar to the failed one.

   text	   data	    bss	    dec	    hex	filename
  40646	   3384	   6400	  50430	   c4fe	/home/gs/src/RIOT-Xtensa-ESP.working/tests/libc_newlib/bin/esp32-wroom-32/tests_libc_newlib.elf
Test: comparing addresses of 'printf' and 'iprintf' symbols
[SUCCESS] '400d0334' = '400d0334' is True

[benpicco]

Code looks good!

[gschorcht]

I have realized that %llu debugging outputs don't work any longer with the newlib-nano-formatted-io. According to @kaspar030's comment #13812 (comment) it might be better to replace them by %u debugging outputs before this PR is merged instead of reverting newlib-nano-formated-io. There are probably other places where %llu is used in debugging outputsand we could replace them by%u` outputs by a separate PR. What do you think?