Hi,
we are using CustomRTCSync with a Colibri T20 module (WEC7 image 2.3) as described here RTCSync code for Colibri iMX6 - Technical Support - Toradex Community. Due to EOL of T20 modules we decided to proceed with iMX6DL. The example is not compatible to the new libraries we need to use with Colibri iMX6 modules (WEC7 image 1.8). Do you have any updated CustomRTCSync example which is using the new libraries?
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
For transitioning from the Colibri T20 to the Colibri iMX6DL module, it’s important to note that while both modules are supported by Toradex, the software environments between them, especially concerning the Windows Embedded Compact (WEC) images, differ significantly from the Linux-based environments and the Torizon platform.
Given your specific requirement for an updated CustomRTCSync example compatible with the Colibri iMX6 modules using WEC7 image 1.8, the approach would typically involve adapting the existing example to the new libraries provided for the iMX6. This adaptation process would include reviewing the library changes between the versions used for T20 and iMX6DL, particularly focusing on any API changes or deprecated functions that could affect the CustomRTCSync functionality.
However, as your question pertains to a Windows Embedded Compact environment rather than Linux or Torizon, it falls outside the Linux-focused expertise I can provide. For Linux-based applications or transitioning to Torizon from WEC7, I could offer detailed guidance on leveraging the Yocto Project, configuring the Linux kernel, or utilizing real-time capabilities with the iMX6DL module.
For Windows Embedded Compact-specific support, including updated examples for CustomRTCSync with the new libraries, I recommend consulting resources specific to that environment or exploring community forums and technical documentation that address WEC7 development for the iMX6DL.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Set up the Torizon IDE Extension Environment | Toradex Developer Center.
The WEC7 image provided by Toradex includes the RTCsync application, which supports the following RTC ICs: ST M41T0, Dallas DS1339, Dallas DS3231, Epson RX-8564LC, ST M41T81, TI TPS658643, and TI TPS65911x. This application is self-contained and does not require any additional libraries.
If your carrier board uses an RTC IC not listed above, we can provide the source code for RTCsync so that you can implement your own SetRealTime() and GetRealTime() functions to work with your specific RTC IC. If you’ve already implemented these functions for the T20, you just need to refactor them using the new Toradex CE Libraries.
Hi Alex,
we are using DS3231 which is supported by WEC7. The standard RTCsync application works well when I it use it in WEC7. The IC is behind a multiplexer and when our application is running RTCsync doesn’t work because the IC is behind a multiplexer and our firmware reads data from some other sensors using the same address. We used CustomRTCsync to address the IC correctly. As the IC we are using is already supported by RTCsync, it might be easier to get the source code and implement the changes than reviewing the changes in the libraries. Can you please provide the source code for RTCsync?
The RTCsync application included in the image is based on deprecated Toradex libraries and links them statically, so no external libraries are required. However, sharing the RTCsync code wouldn’t be particularly helpful since you would need to modify it to accommodate the use of the multiplexer you mentioned.
Given that you already have a CustomRTCsync implementation with the necessary functionality, it should be a straightforward task to adapt it using the new libraries’ API. Please note , the I2C_demo included in the new library package provides an example of reading and writing RTC data, which might be useful for your implementation.
Unfortunately, we do not have CustomRTCsync source code based on the new libraries, as they primarily offer a framework. The specific interaction with RTC hardware needs to be implemented by the customer anyway.
Hi Alex,
we made some progress with the implementation and started testing. The new CustomRTCSync.dll seems to work when the CustomRTCSync.exe is started manually. It reads the correct time from the IC. This doesn’t work yet during Windows start. We changed the RTCSync entry in HKLM\init to CustomRTCSync.exe. exe and dll were added to \FlashDisk\System. After Windows start the system time remains in January 2006 until we start CustomRTCSync.exe manually. Is there anything else we need to do to make it work with iMX6? This was the way we used it with T20 modules.
Have you added CustomRTCSync.exe to the [HKEY_LOCAL_MACHINE\init] registry key? ?
Yes, we did.
Please verify if CustomRTCSync.exe started and executed successfully by adding debug messages to its code and checking them via the serial debug port. You may also try starting it later by increasing the number in its Launch{nn} registry key.
A quick test with increased Launch number was not successful. We will proceed with debug logging next week. Do we get more information that way than using the DbgMSgLogger?
The debug messages are sent to both the Message Buffer and UART simultaneously, so you can choose whichever method you prefer.
We couldn’t make CustomRTCSync start automatically. There seems to be a general difference between T20 and iMX6 init. We tried it with the TaskManager instead of RTCSync. I added the ToradexTaskManager to HKLM\init as shown in the screenshot. When I do this on a T20 module, the TaskManager starts automatically. When I apply the same change on an iMX6 module, the TaskManager doesn’t start. Is there anything else that needs to be set in the registry to make it work?
Most likely the FlashDIsk is not ready yet when you try to load The Task Manager. You can try to disable asynchronous Driver loading.
Thanks, that helped a lot. CustomRTCSync works now during system start. We introduced a new problem with that change. CustomRTCSync is delayed by waiting for FlashDisk. We don’t get a valid IP address (DHCP is enabled) because the time is not set yet. I tried to add the Order parameter to HKLM\Drivers\BuiltIn\Wait4FlashDisk to start it earlier. It seems to improve the behavior. Is that the correct approach?
Next step is to modify our own software to make it work reliable. We used I2CLock in our old dll to interrupt other I2C communication while CustomRTCSync was executed. It looks like there is no alternative to this function in the new libraries and we need to implement this part in our firmware. Please let me know if we are overlooking something.
I did some tests. It looks like CustomRTCSync and getting a valid IP address works reliable with disabled asynchronous driver loading.
I checked debug messages for differences between synchronous and asynchronous driver loading. Can you tell me what the WS2 server driver is used for? The debug messages contain a “WS2 server driver is not loaded!” entry when I use synchronous driver loading. Is this normal or do I need to fix it somehow? I attached debug messages for both cases.
Customrtc-syncdriver.log (2.2 KB)
standardrtc-asyncdriver.log (2.0 KB)
Hi @Annika ,
You can safely ignore the “WS2 server driver is not loaded!” message as it come from the AsyncService (used only to wait for WinSockets, (that’s what WS2 stands for) before loading services). This is a false error as it’s waiting for an event that is only set when asynch loading is enabled. In reality the WS2 service is loaded.
I also wanted to add that there is a much easier way to start your custom RTCSync. Just put it in \Flashdisk\AutoRun The launcher.exe tool will take care of waiting until flashdisk is mounted. So you don’t have to disable the Asynch load.
Also it’s strange you say that if RTCSync is not run before DHCP process you’ll get no IP… i do that all the time as i don’t have a backup battery on my RTC so the system always boots with an old default time (Jan 1, 2006). But the DHCP process still works for me… it should not involve absolute time, only a lease duration i think.
Hi @germano.tx ,
Thanks for the information about the WS2 driver. Our own software is in the AutoRun folder and would interfere with CustomRTCSync when doing an I2C scan for other devices (some have the same address as the clock). Therefore, this is not a good solution for us.
Just to be sure that we are not overlooking another workaround: Is there any way to switch between RTCSync and CustomRTCSync? I think Windows will always use the RTCSync which is in HKLM\init when it applies a time to the external clock. If there is a setting in the registry that allows us to use standard RTCSync in init and CustomRTCSync in case system time is changed later, that would be interesting for us.
I think you are right, that the wrong date is not the reason for our DHCP problem. There is a different problem with the combination of our hardware and iMX6 modules. It looked like it has improved since the time is set correctly, but there is another correlation I overlooked. For some reason we have DHCP problems when there is no USB connection to a PC during a power cycle. We see this problem in our hardware only with iMX6 but not with T20. But I can see that iMX6 modules would get an IP address without USB connection in the Colibri Evaluation board. I think this part of our problem needs a bit more investigation from our side and doesn’t belong to the RTC sync topic.
If you have an RTCSync entry in [HKEY_LOCAL_MACHINE\init], RTCSync will start at each boot according to the order defined by the LaunchNN parameter. You can then start CustomRTCSync by invoking it from your application at any desired time.
@alex.tx This works when we start CustomRTCSync to get the time from the external clock, but I think Windows would still use the standard RTCSync to update the external clock if we change the system time. I think we need to keep CustomRTCSync in init if there is no way to change it.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Transitioning from the Colibri T20 to the Colibri iMX6DL module involves updating your CustomRTCSync implementation to be compatible with the libraries used in the iMX6 modules. Here are some steps to help you adapt your code:
Review the iMX6 Libraries: Begin by examining the libraries available for the Colibri iMX6 running on the WEC7 image 1.8. Ensure you have the latest versions, as these libraries may have different APIs or functionalities compared to those used with the T20 module.
Identify Differences: Look for any differences in hardware interfaces and library functions between the T20 and iMX6 modules. Understanding these differences is crucial for making the necessary changes to your CustomRTCSync code.
Update Your Code: Modify your CustomRTCSync code to utilize the appropriate functions and interfaces provided by the iMX6 libraries. Pay close attention to changes in function signatures, data types, or initialization procedures.
Thorough Testing: After updating your code, conduct thorough testing on the iMX6 module to ensure it functions as expected. Verify that the RTC synchronization works correctly and that there are no compatibility issues.
Consult Documentation: Refer to the Toradex documentation for the Colibri iMX6 module for specific guidance on using the libraries and handling RTC synchronization. This can provide additional insights and best practices.
By following these steps, you should be able to adapt your CustomRTCSync implementation for the iMX6 module. If you encounter specific challenges, consider exploring community forums or technical resources related to the iMX6 module for further insights.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
