Problem with system time in lpc176x bsp
Daniel Gutson
daniel.gutson at tallertechnologies.com
Mon Jan 4 20:49:04 UTC 2016
On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>>
>>
>> On 23/12/15 22:22, Marcos Díaz wrote:
>>
>>> That patch didn't work,
>>> one reason is that it has a mistake:
>>> in kern_tc.c you defined this macro:
>>>
>>> #define _Timecounter_Release(lock_context) \
>>> + *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)
>>>
>>> I think you meant:
>>>
>>> *_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, lock_context)
>>>
>>
>> Its strange, that this didn't lead to failures in Qemu.
>>
>>
> Qemu doesn't do cycle or instruction level simulation.
>
I'm not sure if I fully understand this statement, but FWIW qemu can do
per-instruction emulation, in fact I fixed one 7 years ago
https://lists.nongnu.org/archive/html/qemu-devel/2009-08/msg01153.html
> It does blocks of instructions between potential control flow points.
> Perhaps this is enough to make real hardware and the simulation behave
> differently in this case.
>
> For sure, it reduces the potential race conditions showing up in SMP
> applications since it is alternating blocks of instructions on each
> simulated core.
>
>
>>
>>> The other reason is that as I said, the driver checks for the flag
>>> PENDSTSET of the ICSR register, and I think this approach is wrong, because
>>> that flag goes down when the tick interrupt is attended. I used the
>>> solution I proposed before, but I'm still seeing some errors. I'll let you
>>> know what I find.
>>>
>>
>> Would you mind testing the attached second version of the patch?
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail : sebastian.huber at embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype: dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160104/aae5a691/attachment-0002.html>
More information about the devel
mailing list