Hello,
I am having a problem with the module time with a VF50 running WinCE6.0 image V1.5b4 using an external RTC: M41T81S. RTCSync address: 0x68, protocol 4.
The RTCSync utility does not seem to clear the HT bit (Register: 0x0C bit: D6) before retrieving the date and time from the RTC. Since the HT (Halt update) bit is not cleared, the date and time in the RTC registers does not update, so basically the time is always reset to to the last time the clock was set every time the device is restarted.
The HT bit is set whenever power is restored to the RTC (whether on it is on backup battery or not), so this bit needs to be cleared whenever the module starts up before retrieving to date and time to set on the module.
“the time is always reset to to the last time the clock was set”
This looks more like the STOP bit (register 0x01, bit D7) does not get cleared, or the oscillator does not work.
If it was about the HT bit, the RTC should report the time of power-off, not the last time set.
Unfortunately I don’t have a M41T81S here to test it. However, I checked the RTCSync source code:
- We do clear the HT bit each time just before reading the date and time.
- We do clear the STOP bit each time we set the clock in the RTC
Maybe your M41T81S never starts to oscillate? There is a kickstart procedure mentioned in the datasheet.
RtcSync only accesses the M41T81 during the boot phase and when a new system time is set. It is safe to use our i2c library to read/write its registers from your own application in order to track down the issue.
There is an M41T81S on the hardware that we sent to Toradex for debugging the Audio Driver problem.
I cleared the oscillator fail flag manually and it has not come back on. But the HT is set whenever I check the registers after startup. This is difficult to check since the I2C library and the RTCSync utility require different driver settings. But keeping power applied after starting with RTCSync active and changing the registry for the I2C library and using the UpdateTool to reset the Colibri, I see that the HT bit is still set in the RTC registers and the date and time registers are not updating.
Do you check that the HT bit is cleared?
You can disable RtcSync and query/control the special bits from your own application.
What do we need to do beside clearing the HT bit, before reading the time from the RTC?
Please understand that we have limited resources and cannot debug customer hardware. As mentioned I verified the source code, where I clearly see that the HT bit gets cleared.
It should be easy for you to verify this by monitoring the i2c signals with an oscilloscope or logic analyzer.
I came in this weekend to capture the I2C transfer between the Colibri VF50 and the RTC. Although the RTCSync utility might be attempting to clear the HT bit on the RTC, that intention is not making it to the I2C transfer as you can see on the attached screen capture from a TotalPhase Beagle SPI/I2C sniffer. I started the module with a power on twice and then
ran the RTCSync utility twice during this capture over a period of about 10 minutes. None of the transfers cleared the HT bit and all 4 responses from the RTC decoded to the exact same time.
It looks like the RTCSync utility might be trying to do something before retrieving the time, but it is not currently being successful. The corrupt transaction before the actual transfers is a single pull down on both the data and clock lines about 3 seconds before the actual transfers. Decoding the oscilloscope traces corroborates the data in the screen attached capture.
In the attached image indices 0 to 7 are the initial power on. After 7 I powered down, waited about 4 minutes and powered back on. I then waited about another 3 minutes and ran the RTCSync utility on the device, waited about another three minutes and ran hte RTCSync utility again. The I2C capture was running continuously.
I think my hardware is working (both the SCL and SDA lines are high when data is not being transferred and get pulled full scale when activated).
For completeness, the second power on was at index 8 and the RTCSync utility was launched from Windows Explorer at indices 16 and 22.
The analyzer results helped to locate a bug in our RtcSync tool, which only gets effective for Protocol 4 (M41T81S):
Reads and writes always start at register 0x00 of the M41T81S.
This will be fixed in the next image release V1.5b6.
Meanwhile you can use the RTCSync_Vyb_CE6_1.5b6.exe attached to this answer.
To use it:
- Rename the file to RtcSync.exe
- Copy RtcSync.exe to your target device, e.g. to \Flashdisk\RtcSync.exe
- Modify the registry:
[HKLM\Init]
Launch48=“\Flashdisk\RtcSync.exe”
(The corrupt transactions shown in the analyzer are intentional - they are part of a recovery algorithm we use to re-initialize slave devices which were interrupted in the middle of a byte-read operation.)
Thank you.
The updated software seems to work as it should.
Any idea when V1.5b6 will be released?
The plan is to release 1.5b6 before Nov 25, 2017