bootloop connecting to ntp

[bluexp1]

This is the log from 1.12.5a:
`connected with m.t, channel 1
ip:192.168.1.10,mask:255.255.255.0,gw:192.168.1.1
ip:192.168.1.10,mask:255.255.255.0,gw:192.168.1.1
wifi evt: 0
wifi evt: 3
:ur 1
[004581] [WIFI] MODE STA -------------------------------------
[004585] [WIFI] SSID m.t
[004589] [WIFI] IP 192.168.1.10
[004593] [WIFI] MAC 2C:3A:E8:39:10:69
[004598] [WIFI] GW 192.168.1.1
[004602] [WIFI] DNS 8.8.8.8
[004606] [WIFI] MASK 255.255.255.0
[004610] [WIFI] HOST ESPURNA_391069
[004613] [WIFI] BSSID 50:2B:73:26:40:59
[004616] [WIFI] CH 1
[004619] [WIFI] RSSI -60
[004621] [WIFI] ----------------------------------------------
[004640] [MDNS] OK
[005646] [MQTT] MQTT brokers found: 0
[hostByName] request IP for: pool.ntp.org
[hostByName] Host: pool.ntp.org IP: 194.225.50.25
:ur 1
[008327] [NTP] Error: NTP server not reachable
[hostByName] request IP for: pool.ntp.org
[hostByName] Host: pool.ntp.org IP: 194.225.50.25
:ur 1
[009839] [NTP] Error: NTP server not reachable
[hostByName] request IP for: pool.ntp.org
[hostByName] Host: pool.ntp.org IP: 194.225.50.25
:ur 1
[011356] [NTP] Error: NTP server not reachable
[hostByName] request IP for: pool.ntp.org
[hostByName] Host: pool.ntp.org IP: 194.225.50.25

ets Jan 8 2013,rst cause:4, boot mode:(3,2)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld`

Also I'd like to know how I can factory reset device when flashing esp?

[bluexp1]

also this log may help:

[013129] [NTP] Error: NTP server not reachable
[013139] [NTP] Time:
:urd 137, 137, 0
pm open,type:1 0
Fatal exception 0(IllegalInstructionCause):
epc1=0x39373035, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Exception (0):
epc1=0x39373035 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: sys
sp: 3ffffc20 end: 3fffffb0 offset: 01a0

stack>>>
3ffffdc0: 0000002e 3fff41d4 3fff4784 401046e9
3ffffdd0: 3fff45bc 00000000 3fffc200 000000c4
3ffffde0: 0000001c 00000001 40104526 3fff4209
3ffffdf0: 3fff41d4 3fff41d4 3fff45bc 40104855
3ffffe00: 4023580f 3fff45bc 3fff4602 40235818
3ffffe10: 00000008 3ffffe40 3ffefde0 42d60000
3ffffe20: 40101ef9 3ffefde0 60000200 3fff4610
3ffffe30: 3fff45bc 3fff7258 3fff41d4 4023b8d1
3ffffe40: 005e0001 0000fb00 00000000 60009a00
3ffffe50: 00000018 3fff7258 3fff45bc 4023c35c
3ffffe60: 00000080 3ffecc88 3fff2c6c 00000000
3ffffe70: 3ffffee4 00000001 00000000 00000002
3ffffe80: 3fff415c 00000004 3fff7254 4023c9cc
3ffffe90: 00000000 00000000 0000001f 3fff7254
3ffffea0: 00000000 3fff45bc 3fff4628 4023c39c
3ffffeb0: 3fff41d4 3ffffee0 00000004 3fff7254
3ffffec0: 00000016 3fff41d4 3fff7254 4023bb29
3ffffed0: 3fff41d4 3ffffee0 00000004 401007ac
3ffffee0: 00000494 0104a8c0 3ffec060 4023c9cc
3ffffef0: 3fff7258 3fff41d4 3fff2d54 40235874
3fffff00: 3fff2c6c 0000000d 0000000d 00000002
3fffff10: 3fff4154 3fff41d4 3fff7254 4023becc
3fffff20: 4023685c 3fff3e1c 3fff4304 3fff3e18
3fffff30: 4023685c 3fff3e1c 3ffec058 4023686a
3fffff40: 40105344 0057177e 00000642 40236928
3fffff50: 3ffec058 00000000 00000001 4022b4cd
3fffff60: 402566fc 3fff1648 3fff1670 60000600
3fffff70: 01164743 3fff1670 3fff1648 40256709
3fffff80: 4025674e 3fffdab0 00000000 3fffdcb0
3fffff90: 3fff1688 3fffdad0 3fff2d54 4022b467
3fffffa0: 40000f49 3ffec450 3fffdab0 40000f49
<<<stack<<<

ets Jan 8 2013,rst cause:4, boot mode:(3,2)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld

[Geitde]

You can put gpio0 to GND at runtime. This will reset the device.

There are different modes depending on the duration of holding the pin to GND, but factory reset should be around 5 or 10 seconds.

[bluexp1]

It seems this problem is related to 2.4.0 firmware, I downgraded to 2.3.0 and the bootloop problem solved. but still ntp can not sync

[mcspr]

@bluexp1 can you try different ntpclient version? I was too having similar issue with Core 2.4.0, maybe updated client will handle this better. Running this right now with bogus ip and it seems fine

--- a/code/platformio.ini
+++ b/code/platformio.ini
@@ -30,1 +30,2 @@ lib_deps =
-    https://github.com/gmag11/NtpClient.git#28af3a5
+    https://github.com/gmag11/NtpClient.git#2d51f686
+    ESPAsyncUDP

[xoseperez]

Any update on this? @bluexp1, note that currently ESPurna uses a forked version of the NtpClient library.

https://github.com/xoseperez/NtpClient.git#0016a59

[bluexp1]

Sorry for late reply, I tested 1.13.1 compiled binaries but the problem still exists, How can I make sure it is not related to the network?

[xoseperez]

The ESPurna binaries are compiled against 2.3.0. According to a previous message from you it should work.
Can you check the NTP service from a different device on the same network?

[bluexp1]

I tested in windows using NTP tool from the same network, and there is not any network problem.
NTP is not working for me with either 1.12 or 1.13 precompiled binaries.

[mcspr]

Can you also check mqtt connection with "test.mosquitto.org"? edit: nvm tethering

What I was seeing may or may not be connected though. I did some cable management recently and repositioned some network devices, so it became ISP - MAIN AP - DHCP server - OTHER AP, etc. - ... When testing, ESP was using MAIN AP and was receiving gateway from DHCP, so any internet access routed MAIN -> DHCP_GW -> MAIN again -> ISP -> target. LAN worked ok (ntp, mqtt were working). Other non-esp devices worked fine and were with internet access, only linux ping displaying 'New nexthop' helped discover this.
Assigning static gw=MAIN's ip helped with accessing internet.

[bluexp1]

Mqtt is working fine and I am already using static ip for esp,
Is there any way I can debug this problem?

[mcspr]

Try with different ntp server outside lan? Original logs included only one possible ip for 'pool.ntp.org'

If NtpClient is doing something wrong, try out sdk client: https://github.com/esp8266/Arduino/blob/master/libraries/esp8266/examples/NTP-TZ-DST/NTP-TZ-DST.ino
https://github.com/esp8266/Arduino/blob/master/libraries/esp8266/examples/NTP-TZ-DST/NTP-TZ-DST.ino#L60 <- to change server

As last resort, there is LWIP debug (might be incomplete, but i think it will be enough to enable it):
#define LWIP_DEBUG
#define UDP_DEBUG LWIP_DBG_ON

[mcspr]

@xoseperez on possible solutions for this

• Include asyncudp branch updated with dns resolver, got it working at gmag11/NtpClient@AsyncUDP...mcspr:async-dns . it is directly using lwip api and does make ntpclient api really strange but frees up 'now()' / initial 'NTP.begin()' from locking things up with non-configurable 10sec delay. This is the easiest one.
• Migrate to 2.4.0+ as minimum supported version to support lwip2+built-in sntp (although it should really be 2.4.2, because lwip2 is somewhat unstable with base 2.4.0)
• Include custom dns resolver code inside espurna that does resolving and gives it to ntpclient. This is bad for internet ntp servers because ip can change but can be mitigated by replacing timelib sync function with wrapper around original one.
  dev...mcspr:dns-resolver
  (as a bonus - cli 'nslookup')

edit: correction: sntp is supported in 2.3.0, but got some quirks. and it also does not support TZ data like the new one does.
edit: dns-resolver comment

[bluexp1]

The "ntpclient" example project is working fine with "pool.ntp.org" server, so it seems that the problem is not my network.
What is the real difference between ntpclient example and ntpclient of espurna?

[mcspr]

SDK's SNTP from previous comment or NtpClient one?. If SDK - completely different operation model. If NtpClient - slightly different settings. Which reminds me of one thing I did not think about previously:

espurna/code/espurna/config/general.h

Line 1044 in daf7864

#define NTP_TIMEOUT 1000 // Set NTP request timeout to 2 seconds (issue #452)

Can you try changing this to 2000? Maybe also 3000 if previous did not work.

And can you also please try mcspr/NtpClient:async-dns instead of NtpClient (make sure not to keep old one in library storage)? Keeping changed timeout value. Would be helpful to verify that this approach works too.

[bluexp1]

I used ntpclient example project from arduino example projects.
Changing NTP_TIMEOUT to 3000 did not solve the problem.
but using mcspr/NtpClient:async-dns, NTP is working great without any problem and without changing NTP_TIMEOUT.
Thank you very much.

[xoseperez]

So it looks like using the version based on AsyncUDP might be the best option, right? @mcspr you said it's somewhat "dirty" yet. Maybe we can talk to @gmag11 to see what missing to be released. Also, AsyncUDP requires 2.4.X and that means quite a few more kb of firmware size.

[mcspr]

Also see gmag11/NtpClient#60

I blanked on version requirements, last checking only with esp32 and latest esp8266 git. ESPAsyncUDP uses udp_set_multicast_netif_addr macro that got introduced somewhere between 2.3.0 and 2.4.0.
True, async one is the best option. Either SNTP or using AsyncUDP. Current one is prone unexpected issues with bad wifi connection, using internet servers, wrong domain names, now() implicitly calling NTP.getTime() and blocking etc.

And btw, about configTime. It is still available on Core 2.3.0. Need to verify that periodic syncing is working though, as I got some notes mentioning that it may not trigger (no source, will look into in)

[gmag11]

Hi, AsyncUDP version is working for ESP8266 but not for ESP32. That's the reason because I've not released it.
As you can read on gmag11/NtpClient#60, DNS resolve is not asynchronous yet. So, this can be an issue if your DNS delays answers a lot.
I have to say that, currently, due to my job requirements I cannot dedicate enough time to my programming projects. So I cannot promise much about improve this. :((

[mcspr]

Size being one consern, some preliminary testing with travis02 base:
550592 with NtpClient / TimeLib: https://travis-ci.org/xoseperez/espurna/jobs/437480604#L540
556080 custom branch with configTime and barebones replacement ntp.ino (WIP): https://travis-ci.org/mcspr/espurna/jobs/438964096#L540

Locally, using LWIP2_* in build_flags:
543152 - with NtpClient / TimeLib
546064 - with configTime

I'd still strongly consider moving core base up. 3.0 SDK support is coming with configurable sleep mode, so it could also be enabled again; signed Updater/OTA coming; lwip2 instead of lwip1.4; AsyncUDP as a feature at all to maybe use multicast for local brokerless control etc. This should be a separate issue though.

[xoseperez]

This will mean two-step upgrades for everyone.

[mcspr]

sliding into OT: Not necessarily, as the biggest .bins are with light support. Or web, for that matter. And generic relay modules like itead-sonoff-basic or nodemcu-lolin are still less than 500K.

One of the fat ones - gizwits-witty-cloud
Current 'dev', without sntp changes. Using arduino/esp8266@8ef21ca3ae +lwip2
534416 WEB/UI/API=1
471200 WEB/API=1, no UI
407152 WEB/UI/API=0

Or, another option is to disable debug:
508080 WEB/UI/API=1, DEBUG_SUPPORT=0, TELNET=0, TERMINAL=0 (i.e. only web ui as interface)

Extending HTTP API + implementing v2 changes would soften the need for web.
One can also ship a static binary talking with the device over the HTTP, as a configurator replacement. Or an electron app...

[mcspr]

Closing via #2132

[gmag11]

I've released a new library whose focus is using internal time functions on ESP8266 and ESP32. It uses same interface concept as NTPClientLib with little modifications and additions but is more robust because it uses built in LWIP udp communication instead AsyncUDP library. Have a look here: https://github.com/gmag11/ESPNtpClient