On Tue, Aug 14, 2018 at 7:34 PM, Joel Sherrill wrote:
>
>
> On Sun, Aug 12, 2018 at 4:47 PM, Amaan Cheval
> wrote:
>>
>> Hi!
>>
>> I've narrowed the issue down to this bintime function:
>>
>> https://github.com/RTEMS/rtems/blob/b2de4260c5c71e518742731a8cdebe3411937181/cpukit/score/src/kern_tc.c#L
On Sun, Aug 12, 2018 at 4:47 PM, Amaan Cheval
wrote:
> Hi!
>
> I've narrowed the issue down to this bintime function:
> https://github.com/RTEMS/rtems/blob/b2de4260c5c71e518742731a8cdebe
> 3411937181/cpukit/score/src/kern_tc.c#L548
>
> The watchdog ticks in _Per_CPU_Information / Clock_driver_tic
Hi!
I've narrowed the issue down to this bintime function:
https://github.com/RTEMS/rtems/blob/b2de4260c5c71e518742731a8cdebe3411937181/cpukit/score/src/kern_tc.c#L548
The watchdog ticks in _Per_CPU_Information / Clock_driver_ticks are at
"1000", when that function is called (rtems_clock_get_tod
There's another issue I'm having now:
At -O0, ticker.exe works well and passes reliably. At -O2, the TOD
seems to be rushed a bit:
TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA1 - rtems_
Figured it out; turns out my code to align the stack so I could make
calls without raising exceptions was messing up and corrupting the
stack-pointer.
Running the -O2 code now makes the clock run a bit too quickly - the
calibration may have a minor issue. I'll fix that up and send patches
tomorrow
