Just tried in tsim-leon and happens the same.<div><br></div><div>I didn't completely understand what's the problem Manuel could you explain to me again? is early in the morning :D</div><div><br></div><div>Best regards,</div>
<div><br></div><div>Aitor</div><div><br><br><div class="gmail_quote">On Mon, Mar 30, 2009 at 6:49 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Manuel Coutinho wrote:<br>
><br>
> Hi<br>
><br>
><br>
><br>
> We have discovered a bug of RTEMS relating to the clock. Even though<br>
> we only tested it for the ERC32 board (for now), we believe it is<br>
> common throughout all the targets.<br>
><br>
<br>
</div>No you have discovered a bug in the ERC32's get nanoseconds since last<br>
tick handler.<br>
Apparently it doesn't recognize that is has been longer than a tick<br>
since the last clock<br>
tick.  It should determine that is has overflowed and return 1 clock<br>
tick + partial clock<br>
tick.<br>
<br>
It is returning the wrong answer.<br>
<div class="im"><br>
><br>
><br>
> The test consists in checking if the time given by rtems_clock_get is<br>
> always increasing. The code is as follows:<br>
><br>
><br>
><br>
</div>> .....<br>
<br>
<br>
....<br>
<div><div></div><div class="h5">><br>
> As you can see, the problem is raised when a clock tick occurs: the<br>
> time read in “new” is older than “old”. This cannot happen since “new”<br>
> is updated AFTER “old”! This problem occurs if a clock interrupt is<br>
> triggered after the number of clock ticks have been read but BEFORE<br>
> the nanosecond field has been read. The resulting number of clock<br>
> ticks is “small” (should be plus one).<br>
><br>
><br>
><br>
> We can use the interrupt pending CPU registers info to determine if,<br>
> while we are reading the number of clock ticks that occurred and the<br>
> nanoseconds, a clock interrupt could be pending.<br>
><br>
><br>
><br>
> We do not have enough knowledge to say that this solution can be used<br>
> for all boards (determining if an interrupt is pending). In the SPARC<br>
> architecture, at least, it is possible. If it is possible in all<br>
> architectures, then a solution to RTEMS would be to change the code of<br>
> the _TOD_Get_uptime function to:<br>
><br>
><br>
><br>
><br>
><br>
> void _TOD_Get_uptime(struct timespec *uptime) {<br>
><br>
>     ISR_Level level;<br>
><br>
>     struct timespec offset;<br>
><br>
>     volatile uint32_t pending;<br>
><br>
><br>
><br>
>     /* assume uptime checked by caller */<br>
><br>
><br>
><br>
>     offset.tv_sec = 0;<br>
><br>
>     offset.tv_nsec = 0;<br>
><br>
><br>
><br>
>     _ISR_Disable(level);<br>
><br>
>     *uptime = _TOD_Uptime;<br>
><br>
>     if (_Watchdog_Nanoseconds_since_tick_handler)<br>
><br>
>         offset.tv_nsec = (*_Watchdog_Nanoseconds_since_tick_handler)();<br>
><br>
><br>
><br>
>     /* code added: */<br>
><br>
>     pending = isClockInterruptPending();<br>
><br>
><br>
><br>
>     _ISR_Enable(level);<br>
><br>
><br>
><br>
>     /* code added */<br>
><br>
>     /* if an interrupt occurred while interrupts were disabled and the<br>
> nanoseconds is too little */<br>
><br>
>     /* means that a clock interrupt occurred BEFORE the nanoseconds<br>
> were read */<br>
><br>
>     if (pending && offset.tv_nsec <<br>
> rtems_configuration_get_microseconds_per_tick() / 2) {<br>
><br>
>         struct timespec clockTick = {0,<br>
> rtems_configuration_get_microseconds_per_tick()*1000};<br>
><br>
>         _Timespec_Add_to(&offset, &clockTick); /* so add one clock<br>
> tick to the offset */<br>
><br>
>     }<br>
><br>
><br>
><br>
>     /* else, the clock tick occurred AFTER the nanoseconds were read,<br>
> so no problem */<br>
><br>
><br>
><br>
>     _Timespec_Add_to(uptime, &offset);<br>
><br>
> }<br>
><br>
><br>
><br>
><br>
><br>
> At least, with these modifications, the test passes :)!<br>
><br>
><br>
><br>
> Kind regards<br>
><br>
> Manuel Coutinho<br>
><br>
<br>
<br>
</div></div>--<br>
Joel Sherrill, Ph.D.             Director of Research & Development<br>
joel.sherrill@OARcorp.com        On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
   Support Available             (256) 722-9985<br>
<br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a><br>
<a href="http://rtems.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://rtems.rtems.org/mailman/listinfo/rtems-users</a><br>
</blockquote></div><br></div>