RTEMS - rtems_clock_get_uptime() fails during timer tick

[Joel Sherrill]

On 02/25/2011 03:06 AM, Rolf Schroedter wrote:
> Hi Joel,
> IMO your suggestion to let the nanoseconds handler return a value larger
> than a tick is the cleanest solution.
> I implemented it for the LEON3 BSP and it seems to work.
>
> Fortunately the LEON3 timer has a InterruptPending(IP) hardware flag
> which can be polled and manually reset.
> Therefore two changes were necessary:
>
> 1. Install a LEON3 timer interrupt handler resetting the IP flag on
> every timer tick.
> 2. Change the LEON3 nanoseconds-handler to check the IP flag:
>      read nanoseconds from timer register
>      if ( timer_interrupt_pending )
>           nanoseconds += timer_tick
>
> I'll post the patch to Jiri Gaisler, shall I also post it here ?
>
Please.   If you can also hack it into the other sparc BSPs,
that would be appreciated.

Actually file this as a PR.   This is something I would like
to apply to appropriate release branches.

--joel
> Regards, Rolf
>
> Joel Sherrill wrote, On 24.02.2011 14:28:
>> Can the BSP's get nanoseconds handler return a value that is
>> more than a clock tick?  This case is just on the edge of
>> wrapping the count down timer.  If the counter goes negative,
>> does the get nanoseconds since last tick handler in the
>> BSP "do the right thing"
>>
>> On 02/24/2011 01:51 AM, Rolf Schroedter wrote:
>>> I tried to protect the call to rtems_clock_get_uptime() from interrupts
>>> (this was easier than to recompile RTEMS):
>>>
>>> #define _get_uptime( _ptr_uptime )        \
>>> {                        \
>>>        rtems_interrupt_level   _level;        \
>>>                            \
>>>        rtems_interrupt_disable(_level);        \
>>>        rtems_clock_get_uptime( _ptr_uptime );    \
>>>        rtems_interrupt_enable(_level);        \
>>> }
>>>
>>> But surprisingly (at least for me) this didn't solve the problem.
>>> Okay, I'll try to grab into the RTEMS sources.
>>>
>>> Thanks&   regards,
>>> Rolf.
>>>
>>>
>>> On 24.02.2011 01:23, Gedare Bloom wrote:
>>>> Hi,
>>>>
>>>> I suppose if your code is interrupting the rtems_clock_tick, this
>>>> behavior might happen. Can you try to add an ISR_Disable / ISR_Enable
>>>> protection around the call to "_Timestamp_Add_to(&_TOD_Uptime,&tick
>>>> );" in cpukit/score/src/coretodtickle.c and see if the problem
>>>> disappears?
>>>>
>>>> -Gedare
>>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>