You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
This PSP function is not particularly well-documented. On some systems (pc-linux) it ultimately returns the value of the POSIX "CLOCK_MONOTONIC" clock from the kernel. But on MCP750 it is calculated from a hardware tick counter that wraps every 27 seconds. There is a bunch of logic in CFE TIME to handle handle this wrap.
To Reproduce
The bug is that the background task also samples CFE_PSP_GetTime but does not check for wrap, which works fine on Linux but on VxWorks this probably introduces a timing anomaly every 27 seconds when it wraps. This probably isn't all that noticeable/serious because the background job will just runs an extra cycle and then resume normal operation, but incorrect nonetheless.
Expected behavior
Background job should sample a clock that is known/defined to be monotonic and has consistent/simpler rollover logic.
Alternatives could be the OSAL timebase that drives the 1Hz. However this is not guaranteed to exist on platforms that do not use the RTOS for the 1Hz. So it might be necessary to define a new PSP function, similar to CFE_PSP_GetTime, but is defined to be monotonic and has a more well-defined rollover characteristic. Then this PSP function can just read whatever facility is providing 1Hz signal - RTOS/OSAL, hardware register, or whatever.
With the fix in nasa/PSP#286 this makes it so CFE_PSP_GetTime is properly monotonic and does not wrap - at least not within a few thousand years of uptime.
It would still be good to consolidate CFE_PSP_GetTime() and CFE_PSP_Get_Timebase() such that the latter can be deprecated/removed - having two functions that do very similar things is not really ideal.
jphickey
changed the title
Inconsistent use of CFE_PSP_GetTime
Consolidate CFE_PSP_Get_Timebase and CFE_PSP_GetTime
Mar 31, 2021
Describe the bug
This PSP function is not particularly well-documented. On some systems (pc-linux) it ultimately returns the value of the POSIX "CLOCK_MONOTONIC" clock from the kernel. But on MCP750 it is calculated from a hardware tick counter that wraps every 27 seconds. There is a bunch of logic in CFE TIME to handle handle this wrap.
To Reproduce
The bug is that the background task also samples CFE_PSP_GetTime but does not check for wrap, which works fine on Linux but on VxWorks this probably introduces a timing anomaly every 27 seconds when it wraps. This probably isn't all that noticeable/serious because the background job will just runs an extra cycle and then resume normal operation, but incorrect nonetheless.
Expected behavior
Background job should sample a clock that is known/defined to be monotonic and has consistent/simpler rollover logic.
Alternatives could be the OSAL timebase that drives the 1Hz. However this is not guaranteed to exist on platforms that do not use the RTOS for the 1Hz. So it might be necessary to define a new PSP function, similar to CFE_PSP_GetTime, but is defined to be monotonic and has a more well-defined rollover characteristic. Then this PSP function can just read whatever facility is providing 1Hz signal - RTOS/OSAL, hardware register, or whatever.
Code snips
In particular the code here:
cFE/modules/es/fsw/src/cfe_es_backgroundtask.c
Lines 130 to 131 in fa10af7
This works fine on Linux but likely causes an anomaly every 27 seconds on MCP750 when the clock rolls over.
System observed on:
Found during Inspection when looking at other issues.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: