Hi,
    Did you ever find the solution to the problem?

--- In 68HC12@68HC..., "Oliver Betz" <list_ob@...> wrote:
>
> Hello All,
> 
> setting:
> 
> TCTL1 = 0
> TCTL2 = 0
> OC7D = 2
> OC7M = 2
> 
> should set PT1 once (at TCNT = TC7) and nothing more, correct?
> 
> But I observe that PT1 is reset at TCNT=TC1. IOW, although 
OL1=OM1=0 
> (which means "Timer disconnected from output pin logic"), OC1 
resets 
> PT1.
> 
> The example works also with other OC pins, but I didn't try all of 
> them (only PT1/4/5).
> 
> Anything I overlooked, or shall I file it as an error?
> 
> Oliver
> -- 
> Oliver Betz, Muenchen
>
	

Andy wrote:

>     Did you ever find the solution to the problem?

I already had a solution to avoid the unwanted output compare when I 
posted the error in this list and filed a service request. I simply 
set TC1 so it doesn't trigger during the output waveform I want to 
generate. Well, that slows down my device, but it works.

But it was _very_ hard (more than one month, ~15 mails) to get a 
confirmation from Freescale that it _is_ a bug.

And it's still not published in the errata sheet.

But that's not new to me. Some of my earlier bug reports took more 
than a year until publication or were never published.

Oliver
-- 
Oliver Betz, Muenchen
	

They're trying to cover this bug up in their .pdf for
the ECT.  If you read section 4.2.4 of their ECT pdf,
it says

The pins associated with channels 0-6 become output-tied to OCn 
(n=0...6) when
   * TEN=1, IOSn = 1, and either or both of OMn and OLn are set OR
   * OC7Mn=1, IOS7=1 and IOSn = 1

Read carefully about the OR condition.  So the behavior is 
described.  But I agree with you that
it is obviously a bug that they're trying to cover
up.  I wasted almost a whole day trying to
figure out what those spurious pulses are
coming from.  If wasn't for your post, I'm sure
I'd have wasted much more time.  I'm doing the
same thing as you're.  Basically I'm setting
TC5 and TC6 to TCNT every 5 milliseconds to
avoid having them ever going off.

Thanks.  You're the man for your post.
	--- In 68HC12@68HC..., "Oliver Betz" <list_ob@...> wrote:
>
> Andy wrote:
> 
> >     Did you ever find the solution to the problem?
> 
> I already had a solution to avoid the unwanted output compare when 
I 
> posted the error in this list and filed a service request. I 
simply 
> set TC1 so it doesn't trigger during the output waveform I want to 
> generate. Well, that slows down my device, but it works.
> 
> But it was _very_ hard (more than one month, ~15 mails) to get a 
> confirmation from Freescale that it _is_ a bug.
> 
> And it's still not published in the errata sheet.
> 
> But that's not new to me. Some of my earlier bug reports took more 
> than a year until publication or were never published.
> 
> Oliver
> -- 
> Oliver Betz, Muenchen
>
	

Andy wrote:

> They're trying to cover this bug up in their .pdf for
> the ECT.  If you read section 4.2.4 of their ECT pdf,
> it says
> 
> The pins associated with channels 0-6 become output-tied to OCn 
> (n=0...6) when
>    * TEN=1, IOSn = 1, and either or both of OMn and OLn are set OR
>    * OC7Mn=1, IOS7=1 and IOSn = 1
> 
> Read carefully about the OR condition.  So the behavior is 
> described.  But I agree with you that

No, not by this description. Certainly the pin has to be "output-
tied", that's not what I'm complaining of.

The error is that OLx=OMx=0 does not cause "Timer disconnected from 
output pin logic" as documented in Table 3-2 in section 3.3.8.

So it's not possible to control pins 0..6 only by OC7. In the 
HC12D60A this was different (there were many more "subtle" 
differences...).

> it is obviously a bug that they're trying to cover
> up.  I wasted almost a whole day trying to
> figure out what those spurious pulses are
> coming from.  If wasn't for your post, I'm sure

That's the _really_ annoying thing. I also wasted many hours. Other 
people will also waste precious time only because Freescale doesn't 
publish it!

Again:

Freescale, you waste our time by delaying the documentation of bugs!

Oliver
-- 
Oliver Betz, Muenchen
	

--- In 68HC12@68HC..., "Oliver Betz" <list_ob@...> wrote:
>
> Andy wrote:
> 
> > 
> > The pins associated with channels 0-6 become output-tied to OCn 
> > (n=0...6) when
> >    * TEN=1, IOSn = 1, and either or both of OMn and OLn are set 
OR
> >    * OC7Mn=1, IOS7=1 and IOSn = 1
> > 

Ok,
   Maybe I'm missing something here.  But if you have

   OC7Mn=1, IOS7=1, and IOSn=1, with n=7,6,5

   Then I take from the above description that OC7 will cause output
action on 7,6,5 (from the way OC7 and OC7Mn works) while OC6 will
cause output action on 6 and OC5 will cause output action on 5.
	

Andy wrote:

> > > The pins associated with channels 0-6 become output-tied to OCn 
> > > (n=0...6) when
> > >    * TEN=1, IOSn = 1, and either or both of OMn and OLn are set 
> OR
> > >    * OC7Mn=1, IOS7=1 and IOSn = 1
> > > 
> 
> Ok,
>    Maybe I'm missing something here.  But if you have
> 
>    OC7Mn=1, IOS7=1, and IOSn=1, with n=7,6,5
> 
>    Then I take from the above description that OC7 will cause output
> action on 7,6,5 (from the way OC7 and OC7Mn works) while OC6 will
> cause output action on 6 and OC5 will cause output action on 5.

you should quote the relevant parts of my message.

I wrote:

|The error is that OLx=OMx=0 does not cause "Timer disconnected from 
|output pin logic" as documented in Table 3-2 in section 3.3.8.

Or read my original posting 2005-07-27:
[...]
|But I observe that PT1 is reset at TCNT=TC1. IOW, although OL1=OM1=0
|(which means "Timer disconnected from output pin logic"), OC1 resets
|PT1.

Oliver
-- 
Oliver Betz, Muenchen