Reply by Jefferson Smith ●January 20, 20052005-01-20

I think that it is fine to read only 8 bits of the TC register as long
as you only need the 8 bits. In other words, if you read TC0H then you
would get an 8-bit value that changes slower than if you read the
16-bit TC0.

--- In , "christian_theiss_2003"
<Christian.Theiss@b...> wrote:
...
> ...where was this list I saw on this hcs12 mailing list for
> registers only to be written one time with 1 compound init value,
> not multiple accessing them by bit ORing them...? > CU,
> Christian



Reply by christian_theiss_2003 ●January 20, 20052005-01-20

Hi Edward,

...thanx for all - I discovered it was the ICSYS register which
wasn't set in the right way for latch mode but was set in queue mode
while the other regs were initialised for latch mode!...

...this is a 'write once register', isn't it - in special chip mode
with BDM active setting ICSYS bits by ORing them is allowed, but
actually NOT in 'normal single chip mode'... which created problem
in 'standlone' system running where was set with ICSYS = 2 instead
of 7 for my application with also setting PCMX = 1 to avoid wrapping-
around of 8 bit pulse accumulator counter 0xFF-->0x00...

...where was this list I saw on this hcs12 mailing list for
registers only to be written one time with 1 compound init value,
not multiple accessing them by bit ORing them...? CU,
Christian

--- In , "Edward Karpicz" <karpicz@a...> wrote:
> > Hi Edward,
> Hi, Christian
>
> >
> > ...thanx for your hints and explanations. So as I tried all this
> > before what means in:
> > a) queue mode that
> > latching each pulse accu value into their holding register per
> > TICx access basis each and after this read-in P.A. H.R. into
soft
> > variable
> > b) latch mode that
> > explicitely latching over MCCTL_ICLAT = 1 and after this read-
in
> > P.A. H.R. into soft variable
> >
> I'm not sure I understand what's written above, and am not
sure are you
> understanding me. Code example below may help. Yes, it works in
normal
> single chip mode (D64 2L86D). > //Demonstration of pulse accumulator holding register.
> //Doesn't cover all espects of ECT pulse accumulators, only 8 bit
mode.
> //SCI initialization is done prior main.
> // Queued mode if QUEUEPA defined, latching mode if undefined.
>
> //#define QUEUEPA
> void main(void)
> {
> char tmp;
>
> TSCR1=0x80; // enable timer
>
> DDRT|=3; // set port direction to generate software pulses
>
> PBCTL=0; // 8 bit mode for PA0 and PA1 accumulators
>
> ICPAR|=3; // enable PA0 and PA1 pulse accumulators
>
> TCTL4=(1<<2)+(1<<0); // Setup TIC1 and TIC0 for rising edges
> #ifdef QUEUEPA
> ICSYS=2; // BUFFEN=1, LATQ=0
> printf("Queuing mode\r\n");
> #else
> ICSYS=3; // BUFFEN=1, LATQ=1
> printf("Latching mode\r\n");
> #endif
>
> // Read all registers under question
> printf("After reset: PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0, PA0H,
> PACN1, PA1H);
> // Generate two PA0 pulses
> PTT|=1;
> PTT&=~1;
> PTT|=1;
> PTT&=~1;
> // Generate single PA1 pulse
> PTT|=2;
> PTT &=~2;
> printf("After some pulses PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
>
> // Consecutively try to read TC0H, then TC1, then write one to
ICLAT
> // You may insert more software pulses between lines.
> tmp=TC0H;
> printf("TC0H was read PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
> PTT|= 2+1;
> PTT&=~(2+1);
> printf("One more pulse PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
> tmp=TC1H;
> printf("TC1H was read PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
> PTT|= 2+1;
> PTT&=~(2+1);
> printf("One more pulse PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
> MCCTL|=0x10 ; // write to ICLAT
> printf("ICLAT was written PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
> PTT|= 2+1;
> PTT&=~(2+1);
> printf("One more pulse PACN0=%u PA0H=%u PACN1=%u PA1H=%
u\r\n",PACN0,
> PA0H, PACN1, PA1H);
> }
>
> Output in latching mode:
> Latching mode
> After reset: PACN0=0 PA0H=0 PACN1=0 PA1H=0
> After some pulses PACN0=2 PA0H=0 PACN1=1 PA1H=0
> TC0H was read PACN0=2 PA0H=0 PACN1=1 PA1H=0
> One more pulse PACN0=3 PA0H=0 PACN1=2 PA1H=0
> TC1H was read PACN0=3 PA0H=0 PACN1=2 PA1H=0
> One more pulse PACN0=4 PA0H=0 PACN1=3 PA1H=0
> ICLAT was written PACN0=0 PA0H=4 PACN1=0 PA1H=3
> One more pulse PACN0=1 PA0H=4 PACN1=1 PA1H=3
>
> Output in queued mode:
> Queuing mode
> After reset: PACN0=0 PA0H=0 PACN1=0 PA1H=0
> After some pulses PACN0=2 PA0H=0 PACN1=1 PA1H=0
> TC0H was read PACN0=0 PA0H=2 PACN1=1 PA1H=0
> One more pulse PACN0=1 PA0H=2 PACN1=2 PA1H=0
> TC1H was read PACN0=1 PA0H=2 PACN1=0 PA1H=2
> One more pulse PACN0=2 PA0H=2 PACN1=1 PA1H=2
> ICLAT was written PACN0=2 PA0H=2 PACN1=1 PA1H=2
> One more pulse PACN0=3 PA0H=2 PACN1=2 PA1H=2
>
> IMO above confirms what's written in docs; normal mode, not
special.
>
> > I only get what I had assumed for case b) latch mode and ONLY in
> > special chip mode while adopting my MC9S12A256B controller
system...
> > --> in BDM mode if I set breakpoints I experienced that latching
> > takes some time and also reading P.A. H.R. value into soft
variable,
> > so if my function returns it returns with ZERO P.A. H.R. value in
> > return variable... trying inlining and delaying this also
results in
> > ZERO as for running system in normal single-chip mode without
> > adopting BDM debug toolset!? Could this be really any run-time
issue
> > for this mechanisms taking over P.A. --> P.A. H.R. --> soft
variable?
>
> I have no idea how your debugging toolset updates variables.
Who knows,
> maybe it's reading TIC holding registers continuously resetting
PACNx's?
>
> Edward
>
> >
> > Have you any example code where I had the chance to see this
running
> > just for once in my HCS12 development life cycle[File area]?
> >
> >
> > Thanx in advance, Edward
> >
> > Christian
> >
> >
> > --- In , "Edward Karpicz" <karpicz@a...>
wrote:
> >> Hi
> >>
> >> >
> >> > Hey you guys,
> >> >
> >> > ...does anybody have an idea how the 'holding register'(H.R.)
> >> > mechanism is working in the right way for configuring the ECT
> > timer
> >> > subsystem being used as pulse accumulator("incremental encoder
> >> > accumulator")?
> >> >
> >> > There are 2 general operation modes for "double buffering
> > mechanism":
> >> >
> >> > a) queue mode:
> >> > 1) first H.R. register access should 'queue' pulse accumulator
> >> > (P.A.) values of all 4x 8Bit channels or 2x 16Bit channels,
> >> > respectively, into their dedicated H.R.s
> >>
> >> No. Not all but only associated 8 bit pulse accumulator.
> > Check "Detailed
> >> Timer Block Diagram in Queued mode". You will see how read of
> > TC3H is
> >> wired. It transfers PACN3 into PA3H and resets PACN3.
> >>
> >>
> >> >
> >> > 2)second H.R. register access should READ holding register
into
> >> > soft variable while AT MEANWHILE pulse accumulator can count
new
> >> > encoder increments online, for e.g. in my application setup,
into
> >> > P.A. registers
> >>
> >> Second access should work exactly the same way as first access.
> > Specs say:
> >> "reads of an input capture holding register will transfer the
> > contents of
> >> the associated pulse accumulator to its holding register. At the
> > same time
> >> the pulse accumulator is cleared."
> >>
> >> Pulse accumulator counts pulses on associated input line and
count
> > register
> >> (PACNx) gets incremented. Now when you read input capture
holding
> > register
> >> (TCxH) two things happen in this order: 1. PACNx gets copied to
> > PAxH. 2.
> >> PACNx gets cleared.
> >>
> >>
> >>
> >> >
> >> > b) latch mode:
> >> > 1) firstly explicite latch mechanism over
> >> > - setting modulus counter MCCNT = 0 explicitely
> >> > - setting modulus counter MCCNT = 0 over continuesly 'modulus
> > mode'
> >> > - setting modulus counter MC_LAT = 1 explicitely
> >> > gets P.A. values into their dedicated H.R.s
> >>
> >> Yes all PACNx gets copied to PAxH, PACNx gets cleared when MDC
> > generates
> >> latch pulse.
> >>
> >>
> >> >
> >> > 2) secondly H.R. register READ should READ holding register
into
> >> > soft variable while AT MEANTIME P.A. can count new encoder
> >> > increments online, for e.g. in my application setup, into P.A.
> >> > registers
> >> >
> >>
> >> No secondly.
> >>
> >>
> >> > --> So, provided that I understood everything in the right way
> > from
> >> > the specs I ask myself why queue mode isn't working at all and
> > latch
> >> > mode only works in 'special chip mode' using BDM actively to
> > debug
> >> > my firmware image but isn't working in 'normal single chip'
mode
> >> > where the regs are turning out to be zero all the time,
although
> >> > encoder generates new pulses at the ECT inputs?
> >>
> >> Using BDM actively may mean input capture registers are
> > periodically
> >> accessed. Your BDM POD software may access them to show some
> > memory dump on
> >> your PC display.
> >>
> >>
> >> > Does anybody out there have any idea, if there is maybe a run-
> > time
> >> > problem between BDM mode and standalone normal single chip
mode
> > for
> >> > the 'holding register' latching/emptying mechanism within ECT
> > HCS12
> >> > subsystem just in-time??? I tried including delays between
> > latching
> >> > and reading/emptying access, but it doesn't help at all...
> > perhaps
> >> > are there any multiple register accesses needed?
> >>
> >> Probably problem was that you were accessing pulse accumulator
> > holding
> >> registers intead of inpuy capture holding registers. Double
> > buffering
> >> mechanism? Maybe. I don't see anything double. More than that I
> > don't see
> >> application for queued PA mode. Latched makes some sense because
> > it can (and
> >> should) be used to compare simultaneously counting PAs.
> >>
> >> BTW didn't you have difficulties finding in ECT docs what PORTT
> > pin pulse
> >> accumulators can generate interrupts and what PORTT pin can
> > be "wired" to
> >> 16bit pulse accumulator PA or 16bit pulse accumulator PB? I did.
> > Pin names
> >> do change couple of times per ECT document and further changes
in
> > 9s12d64
> >> device guide. I would read PA holding register instead of TIC
> > holding
> >> register too.
> >>
> >> Regards,
> >> Edward
> >>
> >> >
> >> >
> >> > Hope you could help in any way
> >> > Thanx in advance,
> >> >
> >> > Christian
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >



Reply by Edward Karpicz ●January 20, 20052005-01-20
> Hi Edward,
Hi, Christian

>
> ...thanx for your hints and explanations. So as I tried all this
> before what means in:
> a) queue mode that
> latching each pulse accu value into their holding register per
> TICx access basis each and after this read-in P.A. H.R. into soft
> variable
> b) latch mode that
> explicitely latching over MCCTL_ICLAT = 1 and after this read-in
> P.A. H.R. into soft variable
>
I'm not sure I understand what's written above, and am not sure are you
understanding me. Code example below may help. Yes, it works in normal
single chip mode (D64 2L86D). //Demonstration of pulse accumulator holding register.
//Doesn't cover all espects of ECT pulse accumulators, only 8 bit mode.
//SCI initialization is done prior main.
// Queued mode if QUEUEPA defined, latching mode if undefined.

//#define QUEUEPA
void main(void)
{
char tmp;

TSCR1=0x80; // enable timer

DDRT|=3; // set port direction to generate software pulses

PBCTL=0; // 8 bit mode for PA0 and PA1 accumulators

ICPAR|=3; // enable PA0 and PA1 pulse accumulators

TCTL4=(1<<2)+(1<<0); // Setup TIC1 and TIC0 for rising edges
#ifdef QUEUEPA
ICSYS=2; // BUFFEN=1, LATQ=0
printf("Queuing mode\r\n");
#else
ICSYS=3; // BUFFEN=1, LATQ=1
printf("Latching mode\r\n");
#endif

// Read all registers under question
printf("After reset: PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0, PA0H,
PACN1, PA1H);
// Generate two PA0 pulses
PTT|=1;
PTT&=~1;
PTT|=1;
PTT&=~1;
// Generate single PA1 pulse
PTT|=2;
PTT &=~2;
printf("After some pulses PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);

// Consecutively try to read TC0H, then TC1, then write one to ICLAT
// You may insert more software pulses between lines.
tmp=TC0H;
printf("TC0H was read PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);
PTT|= 2+1;
PTT&=~(2+1);
printf("One more pulse PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);
tmp=TC1H;
printf("TC1H was read PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);
PTT|= 2+1;
PTT&=~(2+1);
printf("One more pulse PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);
MCCTL|=0x10 ; // write to ICLAT
printf("ICLAT was written PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);
PTT|= 2+1;
PTT&=~(2+1);
printf("One more pulse PACN0=%u PA0H=%u PACN1=%u PA1H=%u\r\n",PACN0,
PA0H, PACN1, PA1H);
}

Output in latching mode:
Latching mode
After reset: PACN0=0 PA0H=0 PACN1=0 PA1H=0
After some pulses PACN0=2 PA0H=0 PACN1=1 PA1H=0
TC0H was read PACN0=2 PA0H=0 PACN1=1 PA1H=0
One more pulse PACN0=3 PA0H=0 PACN1=2 PA1H=0
TC1H was read PACN0=3 PA0H=0 PACN1=2 PA1H=0
One more pulse PACN0=4 PA0H=0 PACN1=3 PA1H=0
ICLAT was written PACN0=0 PA0H=4 PACN1=0 PA1H=3
One more pulse PACN0=1 PA0H=4 PACN1=1 PA1H=3

Output in queued mode:
Queuing mode
After reset: PACN0=0 PA0H=0 PACN1=0 PA1H=0
After some pulses PACN0=2 PA0H=0 PACN1=1 PA1H=0
TC0H was read PACN0=0 PA0H=2 PACN1=1 PA1H=0
One more pulse PACN0=1 PA0H=2 PACN1=2 PA1H=0
TC1H was read PACN0=1 PA0H=2 PACN1=0 PA1H=2
One more pulse PACN0=2 PA0H=2 PACN1=1 PA1H=2
ICLAT was written PACN0=2 PA0H=2 PACN1=1 PA1H=2
One more pulse PACN0=3 PA0H=2 PACN1=2 PA1H=2

IMO above confirms what's written in docs; normal mode, not special.

> I only get what I had assumed for case b) latch mode and ONLY in
> special chip mode while adopting my MC9S12A256B controller system...
> --> in BDM mode if I set breakpoints I experienced that latching
> takes some time and also reading P.A. H.R. value into soft variable,
> so if my function returns it returns with ZERO P.A. H.R. value in
> return variable... trying inlining and delaying this also results in
> ZERO as for running system in normal single-chip mode without
> adopting BDM debug toolset!? Could this be really any run-time issue
> for this mechanisms taking over P.A. --> P.A. H.R. --> soft variable?

I have no idea how your debugging toolset updates variables. Who knows,
maybe it's reading TIC holding registers continuously resetting PACNx's?

Edward

>
> Have you any example code where I had the chance to see this running
> just for once in my HCS12 development life cycle[File area]? > Thanx in advance, Edward
>
> Christian > --- In , "Edward Karpicz" <karpicz@a...> wrote:
>> Hi
>>
>> >
>> > Hey you guys,
>> >
>> > ...does anybody have an idea how the 'holding register'(H.R.)
>> > mechanism is working in the right way for configuring the ECT
> timer
>> > subsystem being used as pulse accumulator("incremental encoder
>> > accumulator")?
>> >
>> > There are 2 general operation modes for "double buffering
> mechanism":
>> >
>> > a) queue mode:
>> > 1) first H.R. register access should 'queue' pulse accumulator
>> > (P.A.) values of all 4x 8Bit channels or 2x 16Bit channels,
>> > respectively, into their dedicated H.R.s
>>
>> No. Not all but only associated 8 bit pulse accumulator.
> Check "Detailed
>> Timer Block Diagram in Queued mode". You will see how read of
> TC3H is
>> wired. It transfers PACN3 into PA3H and resets PACN3.
>>
>>
>> >
>> > 2)second H.R. register access should READ holding register into
>> > soft variable while AT MEANWHILE pulse accumulator can count new
>> > encoder increments online, for e.g. in my application setup, into
>> > P.A. registers
>>
>> Second access should work exactly the same way as first access.
> Specs say:
>> "reads of an input capture holding register will transfer the
> contents of
>> the associated pulse accumulator to its holding register. At the
> same time
>> the pulse accumulator is cleared."
>>
>> Pulse accumulator counts pulses on associated input line and count
> register
>> (PACNx) gets incremented. Now when you read input capture holding
> register
>> (TCxH) two things happen in this order: 1. PACNx gets copied to
> PAxH. 2.
>> PACNx gets cleared.
>>
>>
>>
>> >
>> > b) latch mode:
>> > 1) firstly explicite latch mechanism over
>> > - setting modulus counter MCCNT = 0 explicitely
>> > - setting modulus counter MCCNT = 0 over continuesly 'modulus
> mode'
>> > - setting modulus counter MC_LAT = 1 explicitely
>> > gets P.A. values into their dedicated H.R.s
>>
>> Yes all PACNx gets copied to PAxH, PACNx gets cleared when MDC
> generates
>> latch pulse.
>>
>>
>> >
>> > 2) secondly H.R. register READ should READ holding register into
>> > soft variable while AT MEANTIME P.A. can count new encoder
>> > increments online, for e.g. in my application setup, into P.A.
>> > registers
>> >
>>
>> No secondly.
>>
>>
>> > --> So, provided that I understood everything in the right way
> from
>> > the specs I ask myself why queue mode isn't working at all and
> latch
>> > mode only works in 'special chip mode' using BDM actively to
> debug
>> > my firmware image but isn't working in 'normal single chip' mode
>> > where the regs are turning out to be zero all the time, although
>> > encoder generates new pulses at the ECT inputs?
>>
>> Using BDM actively may mean input capture registers are
> periodically
>> accessed. Your BDM POD software may access them to show some
> memory dump on
>> your PC display.
>>
>>
>> > Does anybody out there have any idea, if there is maybe a run-
> time
>> > problem between BDM mode and standalone normal single chip mode
> for
>> > the 'holding register' latching/emptying mechanism within ECT
> HCS12
>> > subsystem just in-time??? I tried including delays between
> latching
>> > and reading/emptying access, but it doesn't help at all...
> perhaps
>> > are there any multiple register accesses needed?
>>
>> Probably problem was that you were accessing pulse accumulator
> holding
>> registers intead of inpuy capture holding registers. Double
> buffering
>> mechanism? Maybe. I don't see anything double. More than that I
> don't see
>> application for queued PA mode. Latched makes some sense because
> it can (and
>> should) be used to compare simultaneously counting PAs.
>>
>> BTW didn't you have difficulties finding in ECT docs what PORTT
> pin pulse
>> accumulators can generate interrupts and what PORTT pin can
> be "wired" to
>> 16bit pulse accumulator PA or 16bit pulse accumulator PB? I did.
> Pin names
>> do change couple of times per ECT document and further changes in
> 9s12d64
>> device guide. I would read PA holding register instead of TIC
> holding
>> register too.
>>
>> Regards,
>> Edward
>>
>> >
>> >
>> > Hope you could help in any way
>> > Thanx in advance,
>> >
>> > Christian >
> Yahoo! Groups Links >
>


Reply by christian_theiss_2003 ●January 20, 20052005-01-20

Hi Edward,

...thanx for your hints and explanations. So as I tried all this
before what means in:
a) queue mode that
latching each pulse accu value into their holding register per
TICx access basis each and after this read-in P.A. H.R. into soft
variable
b) latch mode that
explicitely latching over MCCTL_ICLAT = 1 and after this read-in
P.A. H.R. into soft variable

I only get what I had assumed for case b) latch mode and ONLY in
special chip mode while adopting my MC9S12A256B controller system...
--> in BDM mode if I set breakpoints I experienced that latching
takes some time and also reading P.A. H.R. value into soft variable,
so if my function returns it returns with ZERO P.A. H.R. value in
return variable... trying inlining and delaying this also results in
ZERO as for running system in normal single-chip mode without
adopting BDM debug toolset!? Could this be really any run-time issue
for this mechanisms taking over P.A. --> P.A. H.R. --> soft variable?

Have you any example code where I had the chance to see this running
just for once in my HCS12 development life cycle[File area]? Thanx in advance, Edward

Christian --- In , "Edward Karpicz" <karpicz@a...> wrote:
> Hi
>
> >
> > Hey you guys,
> >
> > ...does anybody have an idea how the 'holding register'(H.R.)
> > mechanism is working in the right way for configuring the ECT
timer
> > subsystem being used as pulse accumulator("incremental encoder
> > accumulator")?
> >
> > There are 2 general operation modes for "double buffering
mechanism":
> >
> > a) queue mode:
> > 1) first H.R. register access should 'queue' pulse accumulator
> > (P.A.) values of all 4x 8Bit channels or 2x 16Bit channels,
> > respectively, into their dedicated H.R.s
>
> No. Not all but only associated 8 bit pulse accumulator.
Check "Detailed
> Timer Block Diagram in Queued mode". You will see how read of
TC3H is
> wired. It transfers PACN3 into PA3H and resets PACN3. > >
> > 2)second H.R. register access should READ holding register into
> > soft variable while AT MEANWHILE pulse accumulator can count new
> > encoder increments online, for e.g. in my application setup, into
> > P.A. registers
>
> Second access should work exactly the same way as first access.
Specs say:
> "reads of an input capture holding register will transfer the
contents of
> the associated pulse accumulator to its holding register. At the
same time
> the pulse accumulator is cleared."
>
> Pulse accumulator counts pulses on associated input line and count
register
> (PACNx) gets incremented. Now when you read input capture holding
register
> (TCxH) two things happen in this order: 1. PACNx gets copied to
PAxH. 2.
> PACNx gets cleared. >
> >
> > b) latch mode:
> > 1) firstly explicite latch mechanism over
> > - setting modulus counter MCCNT = 0 explicitely
> > - setting modulus counter MCCNT = 0 over continuesly 'modulus
mode'
> > - setting modulus counter MC_LAT = 1 explicitely
> > gets P.A. values into their dedicated H.R.s
>
> Yes all PACNx gets copied to PAxH, PACNx gets cleared when MDC
generates
> latch pulse. > >
> > 2) secondly H.R. register READ should READ holding register into
> > soft variable while AT MEANTIME P.A. can count new encoder
> > increments online, for e.g. in my application setup, into P.A.
> > registers
> >
>
> No secondly. > > --> So, provided that I understood everything in the right way
from
> > the specs I ask myself why queue mode isn't working at all and
latch
> > mode only works in 'special chip mode' using BDM actively to
debug
> > my firmware image but isn't working in 'normal single chip' mode
> > where the regs are turning out to be zero all the time, although
> > encoder generates new pulses at the ECT inputs?
>
> Using BDM actively may mean input capture registers are
periodically
> accessed. Your BDM POD software may access them to show some
memory dump on
> your PC display. > > Does anybody out there have any idea, if there is maybe a run-
time
> > problem between BDM mode and standalone normal single chip mode
for
> > the 'holding register' latching/emptying mechanism within ECT
HCS12
> > subsystem just in-time??? I tried including delays between
latching
> > and reading/emptying access, but it doesn't help at all...
perhaps
> > are there any multiple register accesses needed?
>
> Probably problem was that you were accessing pulse accumulator
holding
> registers intead of inpuy capture holding registers. Double
buffering
> mechanism? Maybe. I don't see anything double. More than that I
don't see
> application for queued PA mode. Latched makes some sense because
it can (and
> should) be used to compare simultaneously counting PAs.
>
> BTW didn't you have difficulties finding in ECT docs what PORTT
pin pulse
> accumulators can generate interrupts and what PORTT pin can
be "wired" to
> 16bit pulse accumulator PA or 16bit pulse accumulator PB? I did.
Pin names
> do change couple of times per ECT document and further changes in
9s12d64
> device guide. I would read PA holding register instead of TIC
holding
> register too.
>
> Regards,
> Edward
>
> >
> >
> > Hope you could help in any way
> > Thanx in advance,
> >
> > Christian


Reply by Edward Karpicz ●January 19, 20052005-01-19
Hi

>
> Hey you guys,
>
> ...does anybody have an idea how the 'holding register'(H.R.)
> mechanism is working in the right way for configuring the ECT timer
> subsystem being used as pulse accumulator("incremental encoder
> accumulator")?
>
> There are 2 general operation modes for "double buffering mechanism":
>
> a) queue mode:
> 1) first H.R. register access should 'queue' pulse accumulator
> (P.A.) values of all 4x 8Bit channels or 2x 16Bit channels,
> respectively, into their dedicated H.R.s

No. Not all but only associated 8 bit pulse accumulator. Check "Detailed
Timer Block Diagram in Queued mode". You will see how read of TC3H is
wired. It transfers PACN3 into PA3H and resets PACN3. >
> 2)second H.R. register access should READ holding register into
> soft variable while AT MEANWHILE pulse accumulator can count new
> encoder increments online, for e.g. in my application setup, into
> P.A. registers

Second access should work exactly the same way as first access. Specs say:
"reads of an input capture holding register will transfer the contents of
the associated pulse accumulator to its holding register. At the same time
the pulse accumulator is cleared."

Pulse accumulator counts pulses on associated input line and count register
(PACNx) gets incremented. Now when you read input capture holding register
(TCxH) two things happen in this order: 1. PACNx gets copied to PAxH. 2.
PACNx gets cleared.
>
> b) latch mode:
> 1) firstly explicite latch mechanism over
> - setting modulus counter MCCNT = 0 explicitely
> - setting modulus counter MCCNT = 0 over continuesly 'modulus mode'
> - setting modulus counter MC_LAT = 1 explicitely
> gets P.A. values into their dedicated H.R.s

Yes all PACNx gets copied to PAxH, PACNx gets cleared when MDC generates
latch pulse. >
> 2) secondly H.R. register READ should READ holding register into
> soft variable while AT MEANTIME P.A. can count new encoder
> increments online, for e.g. in my application setup, into P.A.
> registers
>

No secondly. > --> So, provided that I understood everything in the right way from
> the specs I ask myself why queue mode isn't working at all and latch
> mode only works in 'special chip mode' using BDM actively to debug
> my firmware image but isn't working in 'normal single chip' mode
> where the regs are turning out to be zero all the time, although
> encoder generates new pulses at the ECT inputs?

Using BDM actively may mean input capture registers are periodically
accessed. Your BDM POD software may access them to show some memory dump on
your PC display. > Does anybody out there have any idea, if there is maybe a run-time
> problem between BDM mode and standalone normal single chip mode for
> the 'holding register' latching/emptying mechanism within ECT HCS12
> subsystem just in-time??? I tried including delays between latching
> and reading/emptying access, but it doesn't help at all... perhaps
> are there any multiple register accesses needed?

Probably problem was that you were accessing pulse accumulator holding
registers intead of inpuy capture holding registers. Double buffering
mechanism? Maybe. I don't see anything double. More than that I don't see
application for queued PA mode. Latched makes some sense because it can (and
should) be used to compare simultaneously counting PAs.

BTW didn't you have difficulties finding in ECT docs what PORTT pin pulse
accumulators can generate interrupts and what PORTT pin can be "wired" to
16bit pulse accumulator PA or 16bit pulse accumulator PB? I did. Pin names
do change couple of times per ECT document and further changes in 9s12d64
device guide. I would read PA holding register instead of TIC holding
register too.

Regards,
Edward

>
>
> Hope you could help in any way
> Thanx in advance,
>
> Christian
Reply by christian_theiss_2003 ●January 19, 20052005-01-19

Hey you guys,

...does anybody have an idea how the 'holding register'(H.R.)
mechanism is working in the right way for configuring the ECT timer
subsystem being used as pulse accumulator("incremental encoder
accumulator")?

There are 2 general operation modes for "double buffering mechanism":

a) queue mode:
1) first H.R. register access should 'queue' pulse accumulator
(P.A.) values of all 4x 8Bit channels or 2x 16Bit channels,
respectively, into their dedicated H.R.s

2)second H.R. register access should READ holding register into
soft variable while AT MEANWHILE pulse accumulator can count new
encoder increments online, for e.g. in my application setup, into
P.A. registers

b) latch mode:
1) firstly explicite latch mechanism over
- setting modulus counter MCCNT = 0 explicitely
- setting modulus counter MCCNT = 0 over continuesly 'modulus mode'
- setting modulus counter MC_LAT = 1 explicitely
gets P.A. values into their dedicated H.R.s

2) secondly H.R. register READ should READ holding register into
soft variable while AT MEANTIME P.A. can count new encoder
increments online, for e.g. in my application setup, into P.A.
registers

--> So, provided that I understood everything in the right way from
the specs I ask myself why queue mode isn't working at all and latch
mode only works in 'special chip mode' using BDM actively to debug
my firmware image but isn't working in 'normal single chip' mode
where the regs are turning out to be zero all the time, although
encoder generates new pulses at the ECT inputs?
Does anybody out there have any idea, if there is maybe a run-time
problem between BDM mode and standalone normal single chip mode for
the 'holding register' latching/emptying mechanism within ECT HCS12
subsystem just in-time??? I tried including delays between latching
and reading/emptying access, but it doesn't help at all... perhaps
are there any multiple register accesses needed? Hope you could help in any way
Thanx in advance,

Christian