Please be aware that, even deploying on CE6, our VS2008 solution is built for platform Toradex_CE500, due to retrocompatibility issues using the WifiPeekLib project in it).
By the way, Our main reason for this libraries update is the following:
We built project on CE5 with libs 1.7 to deploy on CE6 V1.4B1. We also use I2C1, but we use the builtin rtcsync to save datetime.
Recently we had to adapt to the new CE6 V1.5 .
As I can get from here, in the new image rtcsync was updated to use libraries that no more rely on i2c builtin driver, whereas the old libs linked in our application do, and this cause conflicts. As our app run right after boot (and init i2c), our end users won’t be able to customize date time (saved on external rtc) from inside it.
There was a call in the IntLib which was the source of that incompatibility. I fixed the problem and created a preliminary version of the library, which you can download through the following link:
Thanks @andy.tx,
I were able to compile and deploy our solution with this new libraries.
Now only a small issue is left:
I get that the i2c mutex is locked upon I2c_Open and released with I2c_Close, so I have to halt the threads that read i2c1 and close it to be able to change datetime in external rtc.
But our application is build so that the SetLocalTime call is almost immediately followed by the I2c_Open call.
This, even using the new libs, does not work (date is lost after reboot).
I did some tests by adjusting a Sleep delay in-between the two calls and, the point is:
It seems a minimum Sleep delay of at least 4100ms is to put between SetLocalTime and I2c_Open for the rtc_sync tool to correctly save the datetime into the external rtc.
How come? Can it be fixed somehow? Or do I have to show a loading wheel (4seconds are alot) ?
Thanks for your hints, I will use them asap.
Just a side question: what I have to do to launch rtcsync with the parameter? is enought to add it in the string regedit value of rtcsync under init key?
I’m afraid I have no explanation why this takes so long.
As a short test on a factory-default Colibri VF61, I used the system tray time applet to change the time - this calls SetLocalTime(), and I had debug messages enabled to verify what the RtcSync tool does.
I powered off my board withing half a second after setting the time, and it was perfectly kept after the reboot.
I suggest you need to find out what is different in your setup. Some hints:
Keep the debug messages enabled to get a feedback of the RtcSync operation.
Is your system busy with other tasks, and RtcSync’s priority is low enough to get delayed?
RtcSync is called in reaction of a TimeChangeEvent. Long ago we had issues with a leak in the event database, so events accumulated over time. But this wasn’t even on VF61 modules, so I don’t think this is your problem. However, you can verify whether it is also slow on a freshly setup module.
Try to run RtcSync.exe with the command line parameter AppRunAfterTimeChange. This should copy the Windows system time to the external RTC immediately.
