Thank you for the correction on the
RTC.IsValid property. I’m not sure why I was thinking that it was a state property - probably too many years working with other peripherals that had similar state properties.
So good news and bad news on the RTC.
Good news is the
RTC.Now has accepted setting the time & date without throwing an exception.
Bad news is that the
IsValid property still remains 0 or FALSE regardless.
False before, false after. I can set the RTC clock several times (during my class init(), I set it to an epoch date of 1/1/2023 and if the network is up, I set it again with whatever NTP time I get. - Still false.)
At least I’m not getting an exception thrown when I set it now!
On the WiFi front:
I added an
Enable() call after running the Init() on my wifi module. When called, it immediately kicks out a Connect event and sets the client IP to 0.0.0.0 and a few seconds later, I get the Client IP changed to a proper DHCP provided address. Progress!
So far so good (not sure how or WHY it worked w/o Enable() before…but here we are.)
Bad news here too: I’m noticing that the whole app / debugger to locks-up when I make a call to:
Tracing that call shows that it makes a native call to turn the device ON and another to fetch the Native Rssi value. Not certain which of these two its hanging on, but hang it does - I have to shut down Visual Studio using Task Manager → End Process.
So I’m 30% less convinced it’s a hardware issue as now I’ve been able to poke it and get some positive changes in behavior, but it’s still FAR from how well it was working just late last year.
@Gus_Issa - I’d gladly send chocolates and beer, but the reason I stated (what I believed at the time) to be serious hardware issues precluding further development was because I can’t afford to purchase a replacement board right now. So please accept these virtual Cadbury chocolates and some proper Aussie virtual beer. It’ll have to suffice for now :-\
Thanks all for the input.