[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ERC32 clock counter incorrect



Dear Seronie Vivien,

You are correct about the ERC32 documentation:

Timeout = RTCC * (RTCS+1) / SYSCLK

That is, the RTCC (RTC counter) does not need to add one unit. However, I
must conclude that this is a documentation bug. 

The test performed is roughly like this:

Implemented the General Purpose Timer (Timer 2 on ERC32) with a 1 second
tick. 
This 1 second tick is much larger than the clock tick of 10ms in RTEMS (in
the RTC timer).

I catched the RTC timer interrupt with my own handler

    rtems_interrupt_catch(myclockISR, getClockInterruptNumber(),
oldclockISR);


 which just printed the time read on the GPT:


static rtems_isr myclockISR(rtems_vector_number ignored) {
    uint32_t ticks,nano;

    TIMER2_DRIVER_READ(ticks, nano);
    printk("ticks = %d | nano = %d\n" , ticks,nano);
    oldclockISR(ignored);
}


The time that was printed is always incrementing by one unit (one
microsecond). The output is:

start  0 10050000
start  0 20051000
start  0 30052000
start  0 40053000
start  0 50054000
start  0 60055000
start  0 70056000
start  0 80057000
start  0 90058000
start  0 100059000
start  0 110060000
start  0 120061000
start  0 130062000
start  0 140063000
start  0 150064000
start  0 160065000
start  0 170066000
start  0 180067000
start  0 190068000
start  0 200069000
start  0 210070000
start  0 220071000
start  0 230072000
start  0 240073000
start  0 250074000
start  0 260075000
start  0 270076000
start  0 280077000
start  0 290078000
start  0 300079000
start  0 310080000
start  0 320081000
start  0 330082000
start  0 340083000
start  0 350084000
start  0 360085000
start  0 370086000
start  0 380087000
start  0 390088000
start  0 400089000
start  0 410090000
start  0 420091000
start  0 430092000
start  0 440093000
start  0 450094000
start  0 460095000
start  0 470096000
start  0 480097000
start  0 490098000
start  0 500099000
start  0 510100000
start  0 520101000
start  0 530102000
start  0 540103000
start  0 550104000
start  0 560105000
start  0 570106000
start  0 580107000
start  0 590108000
start  0 600109000
start  0 610110000
start  0 620111000
start  0 630112000
start  0 640113000
start  0 650114000
start  0 660115000
.
.
.


When we add the "-1" the time is always the same (that is, apart from the 10
ms between each clock tick). The output is:


start  0 10049000
start  0 20049000
start  0 30049000
start  0 40049000
start  0 50049000
start  0 60049000
start  0 70049000
start  0 80049000
start  0 90049000
start  0 100049000
start  0 110049000
start  0 120049000
start  0 130049000
start  0 140049000
start  0 150049000
start  0 160049000
start  0 170049000
start  0 180049000
start  0 190049000
start  0 200049000
start  0 210049000
start  0 220049000
start  0 230049000
start  0 240049000
start  0 250049000
start  0 260049000
start  0 270049000
start  0 280049000
start  0 290049000
start  0 300049000
start  0 310049000
start  0 320049000
start  0 330049000
start  0 340049000
start  0 350049000
start  0 360049000
start  0 370049000
start  0 380049000
start  0 390049000
start  0 400049000
start  0 410049000
start  0 420049000
start  0 430049000
start  0 440049000
start  0 450049000
start  0 460049000
start  0 470049000
start  0 480049000
start  0 490049000
.
.
.

Therefore, we conclude that the "-1" is in fact needed.

Note that, even tough we also place the "-1" on the timer2, it is irrelevant
for this test since the timer 2 generates interrupts with one second
interval whereas the timer 1 is generating with 10 ms interval.

Hope this helps

Kind Regards
Manuel Coutinho

> -----Original Message-----
> From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
> On Behalf Of SERONIE VIVIEN, Jacques
> Sent: Monday, March 09, 2009 1:40 PM
> To: rtems-users at rtems.com; GUIBOURET, Damien
> Subject: ERC32 clock counter incorrect
> 
> 
> I just checked ATMEL TSC695F (ERC32) documentation. The formula given to
> compute the duration of the timer does not require a "-1" on the counter
> register (only on the scaler). The documentation states that if the
> counter register is set to 0, the timer is stopped (no interrupt is
> generated), this would not consistent with the "-1".
> 
> But as documentation can contain errors, I would be interested in the
> actual tests you performed to find that the "-1" is required.
> 
> Regards.
> 
> PS: Documentations for LEON2 and LEON3 are differents and clearly
> require the "-1" as it is sait that the timer interrupt is generated
> when the counter underflows.
> 
> 
> Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des
> informations confidentielles et/ou protegees ou dont la diffusion est
> restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le
> copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en
> avertir immediatement l'expediteur et d'effacer ce courriel de votre
> systeme. Astrium decline toute responsabilite en cas de corruption par
> virus, d'alteration ou de falsification de ce courriel lors de sa
> transmission par voie electronique.
> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from disclosure.
> If you are not the intended recipient, please notify the sender
> immediately, do not copy this message or any attachments and do not use it
> for any purpose or disclose its content to any person, but delete this
> message and any attachments from your system. Astrium disclaims any and
> all liability if this email transmission was virus corrupted, altered or
> falsified.
> ---------------------------------------------------------------------
> Astrium SAS (393 341 516 RCS Paris) - Siege social: 6 rue Laurent Pichat,
> 75016 Paris, France
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users