Consider the following test code:
var ntp = "pool.ntp.org";
var list = System.Net.Dns.GetHostEntry(ntp).AddressList;
var ipEndPoint = new System.Net.IPEndPoint(list[0], 123);
You can run that in a regular .NET console app and it’ll work just fine.
Problem is, it was working in my TinyCLR app but now, some 3 weeks later, it’s throwing an “InvalidOperationException” when it tries Dns.GetHostEntry(ntp).AddressList;
Has something changed with DNS resolution?
Here’s the full error trace:
ERROR: Unable to instantiate RTC
Fetching Network time…
#### Exception System.InvalidOperationException - CLR_E_INVALID_OPERATION (1) ####
#### Message:
#### GHIElectronics.TinyCLR.Devices.Network.Provider.NetworkControllerApiWrapper::GetHostByName [IP: 0000] ####
#### System.Net.Dns::GetHostEntry [IP: 000b] ####
#### FEZDuino_PumpMonitor.Hardware.RTC::GetNetworkTime [IP: 001b] ####
#### FEZDuino_PumpMonitor.Hardware.RTC::SetToNTPTime [IP: 0005] ####
#### FEZDuino_PumpMonitor.Hardware.RTC::.ctor [IP: 001b] ####
#### FEZDuino_PumpMonitor.Program::Initialize [IP: 003c] ####
#### FEZDuino_PumpMonitor.Program::Main [IP: 0004] ####
Exception thrown: ‘System.InvalidOperationException’ in GHIElectronics.TinyCLR.Devices.Network.dll
BOARD: FEZ Duino
Note also, that in trying to fetch the RTC, the RTC is never valid now either. I’ve tried everything I know, including this:
var addresses = Dns.GetHostEntry("pool.ntp.org").AddressList;
But it still pops that exception.
OK, this is over-the-top weird now.
After hard coding a NIST time server in there, I now get socket time outs.
The WiFi module appears to be functioning correctly, as it produces a correct list of other AP’s in the vicinity when I use the Scan() method in my WiFi class.
And yes, I re-flashed the device with SITCore-SC20-Firmware-v2.2.0.5100.ghi
Something’s up with the System.Net component of TinyCLR
Exception thrown: 'System.Exception' in GHIElectronics.TinyCLR.Networking.dll
Error contacting NTP server: System.Exception: Socket receive timeout
This site seem very long response on my PC. You may need to extend timeout or set it to infinitive.
For RTC, this is different story. what device are you using?
Dat -
Something is definitely wrong - whatever it is seems to be affecting the networking and the RTC. The device I’m using is the FEZ Duino. I have not touched the code since late November last year - it was working great.
Now, I run the same project and a whole host of problems. So, adhering to my own rules after playing in tech 40+ years: “What did I change last?”
The answer to that is that I have also purchased a Wilderness Labs Meadow development board (Their ProjectLab which comes with a STM32F7 ‘Feather’) and have installed the Visual Studio Plugin.
That’s the ONLY change to my environment, but the namespaces are very different and there’s been zero issues between communicating with the GHI board or the Meadow board. I can easily switch between the two (in fact, I use different USB ports when I do.) No, I don’t run them at the same time or even have them plugged in at the same time.
It might be convenient to blame the Meadow plug-in, but I’d want to know how its affecting the instantiation of the hardware clock on the actual board, as well as how it could possibly be affecting the performance of the TinyCLR version of System.Net
Make sense?
@Dat_Tran – also, I hard-coded the NIST server IP:
//var addresses = Dns.GetHostEntry("pool.ntp.org").AddressList;
IPAddress myAddress = new IPAddress(new byte[] { 129,6,15,27 });
//var ipEndPoint = new IPEndPoint(addresses[0], 123);
var ipEndPoint = new IPEndPoint(myAddress, 123);
var socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.ReceiveTimeout = 5500;
So that got around the Dns lookup error, but it throws another one in its place!
So after more than a few hours of trying to get to the bottom of everything I have come to the unfortunate conclusion that something on the board is broken / failed.
RtcController.GetDefault(); always returns an RTC with ‘IsValid’ set to false. The WiFi module accepts all parameters and initializations, but never connects. (This may be why the Dns.GetHostEntry() is throwing such a strange error.) I can get correct information using the Scan() in the WiFi class - it returns a list of nearby AP’s correctly.
I have tried connecting to two different AP’s - both attempts exhibit identical behavior. Initialization flows through, just never connects. (AP #2 is 13 inches from the device.)
This is unfortunate as it precludes further development on this platform.
Good luck everyone!
As I understand this, we are talking about 2 different things. As for RTC, do you have “enable charge” option? This is optional and needed for the supercap to charge. You may need to enable it and wait for a minute to charge the supercap. You can get a volt meter and measure the supercap if you want to be 100% sure.
rtc.SetChargeMode(GHIElectronics.TinyCLR.Devices.Rtc.BatteryChargeMode.Fast);
https://docs.ghielectronics.com/software/tinyclr/tutorials/real-time-clock.html
Tried the charge command but unfortunately after waiting, the RTC is still not coming back ‘valid’. I’d say 30 some minutes should be plenty of time to let a super-cap charge (brewed some coffee, zombie-scrolled twitter long enough for the end of the second cup) .
Also, the WiFi Scan() for other AP’s now tends to lock-up the app. This is further evidence that there’s an internal hardware failure as the WiFi code hasn’t been changed in the slightest.
For reference, here’s the output of my code:
Initializing interfaces...
Starting RTC
Sleeping 10 seconds to charge RTC..
Starting WiFi connection
Sleeping while WiFi is initialized...
WiFi connect timed-out (no connection after 30 seconds.)
RTC is _not_ operational.
List of AP's: <hangs here>
Have you initialized the RTC with a valid time?
Have you checked your power supply? Power issues cause strange effects.
@Mike You can’t initialize the RTC with a DateTime value until and unless the internal state (provided by IsValid) indicates it is ready. Any attempt to set RTC.Now will cause the setter to throw an exception if IsValid returns false. (As it does.)
You are absolutely correct about power issues. Oh my, I have so many stories.
However, this isn’t the case here. I’ve got it on a sole-use USB3.0 port. That and having switched it around a few times to see if I have a bad port, the behavior doesn’t change.
I don’t see any noise on the line with my o-scope and frankly, if it were a power issue I’d expect my ProjectLab board to exhibit even more problems when I connect it to the PC as it’s larger and has significantly more power draw.
I am not sure this is a correct statement. From the documentation on the RTC:
“In the event the RTC battery was drained or the RTC was never initialized, the RTC will not have a correct value. Use the rtc.IsValid method to determine if the time was set correctly.”
We need your simple code, your output doesn’t help us because they are from your WriteLine, not from firmware.
And, please separate RTC issue, there is nothing relate to WiFi when investigate RTC.
Here is proper way
var rtc = RtcController.GetDefault();
// Rtc is False => Normal because the battery was drained or not set in proper way before.
if (rtc.IsValid == False)
{
// Now set time
var m = new DateTime(2023, 1, 5, 11, 13, 00); // Jan-5-2023
var newDt = RtcDateTime.FromDateTime(m);
rtc.SetTime(newDt );
}
else {
//RTC is valid
SystemTime.SetTime(rtc.Now);
}
If the code above - rtc.IsValid - is always return false then you mau need to charge the battery.
var rtc = RtcController.GetDefault();
rtc.SetChargeMode(GHIElectronics.TinyCLR.Devices.Rtc.BatteryChargeMode.Fast); // fast charge
Thread.sleep(10*1000) ; // 10 seconds
rtc.SetChargeMode(GHIElectronics.TinyCLR.Devices.Rtc.BatteryChargeMode.None); // stop charging
// Then set rtc time again.
You can set time any time, doesn’t matter IsValid is true or false. IsValid only true after time is correct (no before 1979…).
Another case is, if set time was OK and you can read valid time from rtc, but time is lost after disconnect power, meaning the cap need to be recharged.
That is incorrect. “is Valid” does not mean it is ready. Valid means a time was set at some point in the past and the time “isvalid”. You get exception because time is not valid and was not set properly.
Use the code given by Dat and your RTC will simply work.
If it worked, send some chocolates and beer, but if not, let us know and we will continue to help.
All,
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: Winc15x0Interface.GetRssi();
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.
Did you use exactly code like this?
If yes, what is the value when you use rtc.Now? Is the counter running?
Use exactly my code, do not set rtc.Now directly.
For WiFi scanning, it blocks system few seconds, it is known issue.
For GetHostEntry, did you try with other sites?
haha. Virtual candy accepted 