ERC32 clock counter incorrect
Manuel Coutinho
manuel.coutinho at edisoft.pt
Mon Mar 9 15:54:47 UTC 2009
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
More information about the users
mailing list