Problem with system time in lpc176x bsp
joel at rtems.org
Mon Jan 4 17:04:47 UTC 2016
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. 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel