none
System Time in SysTray versus Date/Time Properties Dialog AND OEMSetRealTime RRS feed

  • Question

  • Am using Adeneo/TI Windows Embedded Compact 7 ARM-A8 BSP for AM335X processor Version 02.30.00 with modifications to support our custom designed hardware board.

    Hi,

    We changed the hardware design to make use of an I2C based RTC instead of using the in-built one so I have had to change OEMGetRealTime and OEMSetRealTime to read and write to the I2C RTC device.

    When Windows starts I notice that the the system tray displayed time does not match the time displayed when I open up the Date/Time Properties dialog (opened by double clicking on the system tray time).  After just under a minute the system tray displayed time then syncs up and matches the time in the Date/Time Properties dialog.  Does anyone know why they would display different times initially?

    Also, the system makes a call to OEMSetRealTime and OEMSetAlarmTime on Windows start-up.  Does anyone know why these get called at start-up?

    Thanks

    John

    Wednesday, October 23, 2013 1:44 PM

All replies

  • What is the initial time it is displaying before sync?


    Please mark as answer, if it is correct.
    Please vote,if it is helpful post.
    All the Best
    Vinoth.R
    www.e-consystems.com
    http://vinoth-vinothblog.blogspot.com

    Wednesday, October 23, 2013 2:04 PM
  • The system tray displayed time is saying 12:00am initially.  The Date/Time Properties dialog for example might be saying 4:11AM.
    Wednesday, October 23, 2013 5:12 PM
  • It looks like you aren't initializing the internal RTC when you boot up, but maybe sometime later.

    The time in the internal RTC is typically initialized in when the system calls into KernelIoControl with IOCTL_HAL_INITRTC which in turn calls OALIoCtlHalInitRTC().


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Wednesday, October 23, 2013 6:50 PM
    Moderator
  • As Bruce said i am also suspecting the same.

    Please mark as answer, if it is correct.
    Please vote,if it is helpful post.
    All the Best
    Vinoth.R
    www.e-consystems.com
    http://vinoth-vinothblog.blogspot.com

    Thursday, October 24, 2013 5:44 AM
  • So you can set up your BSP to ignore INITRTC and always return/set the RTC or you can copy the internal processor clock from the RTC chip in INITRTC. I always did the former; clock read/write is a little slower but there's no chance of drift differences between processor clock and RTC chip.

    Paul T.

    Thursday, October 24, 2013 6:59 PM
  • Thanks for everyone's replies.  I need to investigate the IOCTL_HAL_INITRTC and see exactly what my system is doing in this area.  I will update once I have done the investigation. Thanks, John.

    Friday, October 25, 2013 3:20 PM
  • Thanks agains for everyones responses and suggestions.

    It doesn't look the routine OALIoCtlHalInitRTC which exists in the BSP code is getting code as suggested.  Looking into the BSP OAL I can see that g_oalIoCtlTable doesn't contain an entry for IOCTL_HAL_INITRTC.  I have pasted this table at the bottom of the post.  I guess I need to add an entry for IOCTL_HAL_INITRTC in this table and point it to my handler routine and then I will have that routine obtain the time from the external RTC chip.

    Thanks

    John

    { IOCTL_HAL_GET_POWER_DISPOSITION, 0, OALIoCtlHalGetPowerDisposition },

    { IOCTL_HAL_TRANSLATE_IRQ, 0, OALIoCtlHalRequestSysIntr },

    { IOCTL_HAL_REQUEST_SYSINTR, 0, OALIoCtlHalRequestSysIntr },

    { IOCTL_HAL_RELEASE_SYSINTR, 0, OALIoCtlHalReleaseSysIntr },

    { IOCTL_HAL_REQUEST_IRQ, 0, OALIoCtlHalRequestIrq },

    { IOCTL_HAL_IRQ2SYSINTR, 0, OALIoCtlHalIrq2Sysintr },

    { IOCTL_HAL_ILTIMING, 0, OALIoCtlHalILTiming },

    { IOCTL_HAL_REBOOT, 0, OALIoCtlHalReboot },

    { IOCTL_HAL_DDK_CALL, 0, OALIoCtlHalDdkCall },

    { IOCTL_HAL_DISABLE_WAKE, 0, OALIoCtlHalDisableWake },

    { IOCTL_HAL_ENABLE_WAKE, 0, OALIoCtlHalEnableWake },

    { IOCTL_HAL_GET_WAKE_SOURCE, 0, OALIoCtlHalGetWakeSource },

    { IOCTL_HAL_GET_CACHE_INFO, 0, OALIoCtlHalGetCacheInfo },

    { IOCTL_HAL_GET_DEVICE_INFO, 0, OALIoCtlHalGetDeviceInfo },

    { IOCTL_HAL_GET_DEVICEID, 0, OALIoCtlHalGetDeviceId },

    { IOCTL_HAL_GET_UUID, 0, OALIoCtlHalGetUUID },

    { IOCTL_PROCESSOR_INFORMATION, 0, OALIoCtlProcessorInfo },

    { IOCTL_HAL_GET_CPUID, 0, OALIoCtlHalGetCpuID },

    { IOCTL_HAL_GET_CPUFAMILY, 0, OALIoCtlHalGetCpuFamily },

    { IOCTL_HAL_GET_CPUSPEED, 0, OALIoCtlHalGetCpuSpeed },

    { IOCTL_HAL_GET_MAC_ADDRESS, 0, OALIoctlGetMacAddress },

    { IOCTL_HAL_GET_MAC_ADDRESS1, 0, OALIoctlGetMacAddress },

    { IOCTL_HAL_PHYS_TO_VIRT, 0, OALIoCtlNKPhysToVirt },

    { IOCTL_HAL_POSTINIT, 0, OALIoCtlHALPostInit },

    { IOCTL_HAL_I2CCOPYFNTABLE, 0, OALIoCtlHalI2CCopyFnTable },

    { IOCTL_HAL_PADCFGCOPYFNTABLE, 0, OALIoCtlHalPadCfgCopyFnTable },

    { IOCTL_HAL_GET_ECC_TYPE, 0, OALIoctlHalGetEccType },

    { IOCTL_HAL_GET_EBOOT_CFG, 0, OALIoctlGetEbootCfg },

    { IOCTL_PRCM_DEVICE_GET_DEVICEMANAGEMENTTABLE, 0, OALIoCtlPrcmDeviceGetDeviceManagementTable},

    { IOCTL_PRCM_DEVICE_GET_SOURCECLOCKINFO,0, OALIoCtlPrcmDeviceGetSourceClockInfo},

    { IOCTL_PRCM_CLOCK_GET_SOURCECLOCKINFO, 0, OALIoCtlPrcmClockGetSourceClockInfo},

    { IOCTL_PRCM_CLOCK_SET_SOURCECLOCKDIVISOR, 0, OALIoCtlPrcmClockSetSourceClockDivisor},

    { IOCTL_PRCM_CLOCK_SET_DPLLCLKOUTSTATE, 0, OALIoCtlPrcmClockSetDpllClkOutState },

    { IOCTL_HAL_PROFILE, 0, OALIoCtlIgnore },

    { IOCTL_HAL_DUMP_REGISTERS, 0, OALIoCtlHalDumpRegisters },

    { IOCTL_HAL_GET_IRQ_COUNTERS, 0, OALIoCtlHalGetIrqCounters },

    // Required Termination

    { 0, 0, NULL }


    // This file is included by the platform's ioctl.c file and defines the

    // global IOCTL table, g_oalIoCtlTable[]. Therefore, this file may ONLY

    // define OAL_IOCTL_HANDLER entries.

    //

    // IOCTL CODE, Flags Handler Function

    //------------------------------------------------------------------------------

    Wednesday, October 30, 2013 2:26 PM
  • Hi Paul,

    I did have OEMGetRealTime reading the actual time from the RTC, but this routine seemed to be called an awful lot at start-up and seemed to cause some issues. My assumption at the moment is that this is because of the increased processing time of reading the time over the I2C bus.  One of the workarounds I have had to implement currently is to hold off reading the real I2C time until about 5 seconds after boot-up, merely returning a hardcoded time in its place until this point.

    Cheers

    John

    Wednesday, October 30, 2013 3:04 PM
  • I am not sure if you have a question, but you are correct.   You will need to add an entry.

    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Wednesday, October 30, 2013 3:27 PM
    Moderator
  • Hi Bruce,i t was more of an update and seeking confirmation I guess; thanks for the confirmation.

    Cheers

    John

    Wednesday, October 30, 2013 3:30 PM
  • I never encountered any problems of that sort (using I2C) but it's a possibility. I'd expect that returning the same date/time from multiple queries over several seconds might be more of a problem than delaying response to 1.

    If you implement init-RTC to set up the in-chip soft RTC maybe that will correct the startup issues and you can start returning date/time from the real RTC at an appropriate time.

    Paul T.

    Wednesday, October 30, 2013 4:20 PM