Re: Problem with system time in lpc176x bsp

Hi Sebastian, we did some more testing and found out what's causing the problem. Based on what I posted at https://lists.rtems.org/pipermail/devel/2015-December/013235.html, the problem arises when the ticker interrupt occurs while a task is executing one of the instructions that make up the

Re: Problem with system time in lpc176x bsp

At this point, a ticket is needed for anything applied to 4.11 that is not release mechanics related. --joel On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz < marcos.d...@tallertechnologies.com> wrote: > Hi Sebastian, > > we did some more testing and found out what's causing the problem. Based >

Re: Problem with system time in lpc176x bsp

I will issue a ticket. But I noticed that in my patch I include changes to common code that Sebastian suggested, and this will break any other BSP that uses rtems timecounter simple downcounter or upcounter, since these function's signatures changed. Should we update all BSPs? Or make changes more

Re: Problem with system time in lpc176x bsp

On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz < marcos.d...@tallertechnologies.com> wrote: > I will issue a ticket. But I noticed that in my patch I include changes to > common code that Sebastian suggested, and this will break any other BSP > that uses rtems timecounter simple downcounter or

Re: Problem with system time in lpc176x bsp

I made a fast search: These BSPs use *rtems_timecounter_simple_downcounter*: arm/shared/armv7m m68k/mcf52235 m68k/mcf5225x m68k/mcf5329 m68k/uC5282 powerpc/mpc55xxevb sparc/erc32 sparc/leon2 sparc/leon3 sparc/shared These use *rtems_timecounter_simple_upcounter*: powerpc/mpc55xxevb arm/lpc22xx

Re: Problem with system time in lpc176x bsp

Hello, I already created a ticket which blocks the 4.11 release for this bug: https://devel.rtems.org/ticket/2502 I sent a new version of the patch to one of your previous threads some days ago: https://lists.rtems.org/pipermail/devel/2016-January/013289.html There is still a bug in it, since

Re: Problem with system time in lpc176x bsp

Well, we could still use the patch you sent with the protection in is pending, but I think this will break the BSPs I mentioned, since you changed timecounter functions signatures. Am I right? On Mon, Jan 11, 2016 at 4:18 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello,

Re: Problem with system time in lpc176x bsp

On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill wrote: > > > On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber < > sebastian.hu...@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: >>>

Re: Problem with system time in lpc176x bsp

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:

Re: Problem with system time in lpc176x bsp

On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber < sebastian.hu...@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) \

Re: Problem with system time in lpc176x bsp

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,

Re: Problem with system time in lpc176x bsp

Hi, thanks for answering, but spnsext01 test works ok. After a while I noticed the problem: The ticker interrupt has lower priority than any irq. When I entered the ticker: The bit PENDSTSET of the ICSR register that was used to check whether the sysclk had a pending interrupt or not went to 0,

Re: Problem with system time in lpc176x bsp

Hello Marcos, yes, nested interrupts are a problem for the current implementation. Its a general problem of the RTEMS testsuite that we cannot test nested interrupts. I think we have to fix this at some time. Could you please test the attached patch? -- Sebastian Huber, embedded brains GmbH

Re: Problem with system time in lpc176x bsp

Hello, works the spnsext01 test on your target? -- 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.hu...@embedded-brains.de PGP : Public key available on request. Diese

Problem with system time in lpc176x bsp

Hi, i'm using c++ chrono to measure a steady signal periods (With GPIO interrupts), And I see that periodically I have errors of +1ms and then of -1ms. (I discarded GPIOP interrupts problem) I tried using rtems API's rtems_clock_get_uptime_nanoseconds and then I saw the same errors. I'm suspecting

Re: Problem with system time in lpc176x bsp

On Fri, 2015-12-18 at 16:18 -0300, Marcos Díaz wrote: > Hi, i'm using c++ chrono to measure a steady signal periods (With > GPIO > interrupts), And I see that periodically I have errors of +1ms and > then of > -1ms. (I discarded GPIOP interrupts problem) I tried using rtems > API's >