See below.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Lab (417)836-3770
SPRINGFIELD, MO 65897 USA Dept (417)836-5131

"In theory there is no difference between theory and practice. In practice there is." -- Yogi Berra or Jan van de Snepscheut

________________________________________
From: 6... [6...] On Behalf Of tberkau [t...@teksavvy.com]
Sent: Wednesday, August 04, 2010 1:14 PM
To: 6...
Subject: [68HC12] Re: Pulse accumulator question - MC9S12XD256MAG

--- In 6..., Alex Bratovic wrote:
>
> It is possible you get stuck in a different interrupt with higher priority.

I took a look and from what I can tell, there's no other interrupt interfering. Also too, it wouldn't explain why the pulse accumulator is missing events.

ER> I think you are wrong here. If two pulses hit while another interrupt was being processed, only one pulse accumulator interrupt would be generated and thereafter serviced. The same thing could happen if your pulse accumulator interrupt service routine takes too much time.

--- In 6..., Alex Bratovic wrote:
>
> It is possible you get stuck in a different interrupt with higher priority.

I took a look and from what I can tell, there's no other interrupt interfering. Also too, it wouldn't explain why the pulse accumulator is missing events.

It is possible you get stuck in a different interrupt with higher priority.
6... wrote:
> There is 1 message in this issue.
>
> Topics in this digest:
>
> 1a. Re: Pulse accumulator question - MC9S12XD256MAG
> From: tberkau
> Message
> ________________________________________________________________________
> 1a. Re: Pulse accumulator question - MC9S12XD256MAG
> Posted by: "tberkau" t...@teksavvy.com tberkau
> Date: Tue Jul 27, 2010 10:14 am ((PDT))
>
> --- In 6..., "Edward Karpicz" wrote:
>
>> The question was about pulse width. Pulse accumulator may skip too short
>> pulses. What's the pulse width of shortest pulse in your application and
>> what's the bus clock?
>>
>> Edward
>>
>>
>
> I apologize for replying so late, it's been pretty hairy around here. Anyways, here's stats:
>
> Shortest mag pulse width: 400 micro sec
> Avg mag pulse width: 0.6ms
> Bus speed: 25 Mhz
>
> Theo
>
>

--- In 6..., "Edward Karpicz" wrote:
>
> The question was about pulse width. Pulse accumulator may skip too short
> pulses. What's the pulse width of shortest pulse in your application and
> what's the bus clock?
>
> Edward
>

I apologize for replying so late, it's been pretty hairy around here. Anyways, here's stats:

Shortest mag pulse width: 400 micro sec
Avg mag pulse width: 0.6ms
Bus speed: 25 Mhz

Theo

The question was about pulse width. Pulse accumulator may skip too short
pulses. What's the pulse width of shortest pulse in your application and
what's the bus clock?

Edward

----- Original Message -----
From: "tberkau"
To: <6...>
Sent: Thursday, July 22, 2010 11:00 PM
Subject: [68HC12] Re: Pulse accumulator question - MC9S12XD256MAG
> --- In 6..., "Edward Karpicz" wrote:
>>
>> Aren't pulses too short? How pulse width compares to bus clock?
>>
>> Edward
>> I apologize, I should've been more clear. Each tick on the graph
> represents a pulse "event" by the pulse accumulator.
>
>

--- In 6..., "Edward Karpicz" wrote:
>
> Aren't pulses too short? How pulse width compares to bus clock?
>
> Edward
>

I apologize, I should've been more clear. Each tick on the graph represents a pulse "event" by the pulse accumulator.

Aren't pulses too short? How pulse width compares to bus clock?

Edward

----- Original Message -----
From: "tberkau"
To: <6...>
Sent: Thursday, July 22, 2010 5:49 PM
Subject: [68HC12] Re: Pulse accumulator question - MC9S12XD256MAG
> So I've been working on the issue as I described in my past post and I
> have made some progress. I changed the pulse code so it sends an pulse
> overflow interrupt every pulse since I'm only dealing with around 35-40
> mag pulses maximum in a ~500 ms time frame. Anyways, for the most part
> the data is more reliable now. But I still keep running into one weird
> problem, as I tried to explain in my first post. Basically a grouping of
> pulses will magically disappear. You'd think if it was still a case
> where I somehow I was losing pulse counts in my code it at least one or
> two would still remain, but no.
>
> Also, I noticed the total pulses between runs still has a tendency of
> varying dramatically. It should be from 31-38 usually, but I've seen it
> drop down to as low as 22. Here's a couple of simple graphs that help
> illustrate the issue:
>
> Good mag data Bad mag data
>
>

So I've been working on the issue as I described in my past post and I
have made some progress. I changed the pulse code so it sends an pulse
overflow interrupt every pulse since I'm only dealing with around 35-40
mag pulses maximum in a ~500 ms time frame. Anyways, for the most part
the data is more reliable now. But I still keep running into one weird
problem, as I tried to explain in my first post. Basically a grouping of
pulses will magically disappear. You'd think if it was still a case
where I somehow I was losing pulse counts in my code it at least one or
two would still remain, but no.

Also, I noticed the total pulses between runs still has a tendency of
varying dramatically. It should be from 31-38 usually, but I've seen it
drop down to as low as 22. Here's a couple of simple graphs that help
illustrate the issue:

Good mag data

Bad mag data

--- In 6..., "dleatmot" wrote:
>
> I did an EB a long time ago on the PA because of the faster instruction timing in the HC12 and HCS12s versus HC11s that can cause the same code to run differently between the parts, check the Freescale website for EB611, that might be your problem.
>
> Darci

Wow, that's definitely helpful! I'll have to take a look. Thanks.

--- In 6..., "Redd, Emmett R" wrote:
>
> Off the top of my head, the HC11 and HC12 define the Stack Pointer (SP) differently. This should not be a problem if SP is initialized properly in the HC12 code and there are no direct references using an offset from SP. It might be worth checking that both of these are true.
>

Thank you for your suggestion. I did double check the stack and everything checks out fine there.