Closed chabala closed 1 year ago
I see there was a CP 7.2.4 released last week. I have updated, but it is still flaky:
code.py output:
starting...
machine: Raspberry Pi Pico with rp2040
sysname: rp2040
CircuitPython version: 7.2.4 on 2022-03-31
Chip Version: w5100s
MAC Address: DE:AD:BE:EF:FE:ED
IP Address: 192.168.1.195
constructing NTP object
setting RTC via NTP request
Traceback (most recent call last):
File "code.py", line 55, in <module>
File "code.py", line 38, in syncTimeWithNTP
File "/lib/adafruit_wiznet5k/adafruit_wiznet5k_ntp.py", line 58, in get_time
File "/lib/adafruit_wiznet5k/adafruit_wiznet5k_socket.py", line 291, in recv
KeyboardInterrupt:
Updated again:
machine: Raspberry Pi Pico with rp2040
sysname: rp2040
CircuitPython version: 7.2.5 on 2022-04-06
Chip Version: w5100s
MAC Address: DE:AD:BE:EF:FE:ED
IP Address: 192.168.1.195
constructing NTP object
setting RTC via NTP request
Traceback (most recent call last):
File "code.py", line 55, in <module>
File "code.py", line 38, in syncTimeWithNTP
File "/lib/adafruit_wiznet5k/adafruit_wiznet5k_ntp.py", line 58, in get_time
File "/lib/adafruit_wiznet5k/adafruit_wiznet5k_socket.py", line 291, in recv
KeyboardInterrupt:
My latest theory on this is that since NTP uses UDP, on occasion the reply may be lost in transit, and the socket is stuck in a loop waiting to read a reply that isn't coming.
Coincidentally, I've found a PR that sought to improve Wisnet5k UDP handling, but unfortunately it was opened against a Wiznet demo repository instead of this one. I've applied it locally, and while it doesn't solve the hanging issue, it doesn't seem to cause any ill effects either. I don't fully understand all the changes, but it looks like it's solving a mismatch between the number of sockets available and how the existing library handles tracking UDP globally.
I've setup a ntpd daemon on my local network, and after running for a few days, this has almost completely eliminated any hanging behavior, vs using pool.ntp.org
. Not entirely though. But that would suggest that something about how the code handles waiting for the response could be more robust, likely with a bit of timeout and retry logic.
I'm working with the WIZnet
W5100S-EVB-Pico
. As part of troubleshooting another issue, I wanted timestamps, so I configured NTP. I saw there was no NTP example code, so here is my short example code:This works, often, like so:
However, just as often, it hangs in
NTP.get_time()
:line 294 is
gc.collect()
I've also seen this:
This is a bus_device write. Hard to tell if it was stuck there or just stuck in a busy loop in that vicinity.
I'm using the latest stable CP (as shown in the output above), and latest Wiznet5k library.