Hi,
At work we've been migrating our hardware from the MC68HC11A1CFN3 to
MC9S12XD256MAG. Everything is working fine, but we're running into a weird
issue with one magnetic sensor that cropped up. What's happening is when
the pulse accumulator is setup to get pulses from the sensor, it works, but
appears to randomly start losing pulses.
Like for example, say I had magnetic data at points x, y, and z. For the first
3-4 times I run something through it'll pick up all three points. Then the
next time I run something through it'll suddenly lose point x, and next
time it'll be point z that's missing.
I've already tried disabling any unnecessary interrupts or code that could
potentially interfere with data collection. I also try adjusting the delay
counter to see if that would make a difference which it didn't. Does anyone
have any additional ideas of what I could try or what the problem could be? I
can provide additional info if needed.
Pulse accumulator question - MC9S12XD256MAG
Started by ●July 15, 2010
Reply by ●July 15, 20102010-07-15
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.
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: Thursday, July 15, 2010 11:57 AM
To: 6...
Subject: [68HC12] Pulse accumulator question - MC9S12XD256MAG
Hi,
At work we've been migrating our hardware from the MC68HC11A1CFN3 to MC9S12XD256MAG. Everything is working fine, but we're running into a weird issue with one magnetic sensor that cropped up. What's happening is when the pulse accumulator is setup to get pulses from the sensor, it works, but appears to randomly start losing pulses.
Like for example, say I had magnetic data at points x, y, and z. For the first 3-4 times I run something through it'll pick up all three points. Then the next time I run something through it'll suddenly lose point x, and next time it'll be point z that's missing.
I've already tried disabling any unnecessary interrupts or code that could potentially interfere with data collection. I also try adjusting the delay counter to see if that would make a difference which it didn't. Does anyone have any additional ideas of what I could try or what the problem could be? I can provide additional info if needed.
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: Thursday, July 15, 2010 11:57 AM
To: 6...
Subject: [68HC12] Pulse accumulator question - MC9S12XD256MAG
Hi,
At work we've been migrating our hardware from the MC68HC11A1CFN3 to MC9S12XD256MAG. Everything is working fine, but we're running into a weird issue with one magnetic sensor that cropped up. What's happening is when the pulse accumulator is setup to get pulses from the sensor, it works, but appears to randomly start losing pulses.
Like for example, say I had magnetic data at points x, y, and z. For the first 3-4 times I run something through it'll pick up all three points. Then the next time I run something through it'll suddenly lose point x, and next time it'll be point z that's missing.
I've already tried disabling any unnecessary interrupts or code that could potentially interfere with data collection. I also try adjusting the delay counter to see if that would make a difference which it didn't. Does anyone have any additional ideas of what I could try or what the problem could be? I can provide additional info if needed.
Reply by ●July 16, 20102010-07-16
Too short pulses? Wrong code?
Edward
----- Original Message -----
From: "tberkau"
To: <6...>
Sent: Thursday, July 15, 2010 19:57
Subject: [68HC12] Pulse accumulator question - MC9S12XD256MAG
> Hi,
>
> At work we've been migrating our hardware from the MC68HC11A1CFN3 to
> MC9S12XD256MAG. Everything is working fine, but we're running into a weird
> issue with one magnetic sensor that cropped up. What's happening is when
> the pulse accumulator is setup to get pulses from the sensor, it works,
> but appears to randomly start losing pulses.
>
> Like for example, say I had magnetic data at points x, y, and z. For the
> first 3-4 times I run something through it'll pick up all three points.
> Then the next time I run something through it'll suddenly lose point x,
> and next time it'll be point z that's missing.
>
> I've already tried disabling any unnecessary interrupts or code that could
> potentially interfere with data collection. I also try adjusting the delay
> counter to see if that would make a difference which it didn't. Does
> anyone have any additional ideas of what I could try or what the problem
> could be? I can provide additional info if needed.
>
Edward
----- Original Message -----
From: "tberkau"
To: <6...>
Sent: Thursday, July 15, 2010 19:57
Subject: [68HC12] Pulse accumulator question - MC9S12XD256MAG
> Hi,
>
> At work we've been migrating our hardware from the MC68HC11A1CFN3 to
> MC9S12XD256MAG. Everything is working fine, but we're running into a weird
> issue with one magnetic sensor that cropped up. What's happening is when
> the pulse accumulator is setup to get pulses from the sensor, it works,
> but appears to randomly start losing pulses.
>
> Like for example, say I had magnetic data at points x, y, and z. For the
> first 3-4 times I run something through it'll pick up all three points.
> Then the next time I run something through it'll suddenly lose point x,
> and next time it'll be point z that's missing.
>
> I've already tried disabling any unnecessary interrupts or code that could
> potentially interfere with data collection. I also try adjusting the delay
> counter to see if that would make a difference which it didn't. Does
> anyone have any additional ideas of what I could try or what the problem
> could be? I can provide additional info if needed.
>
Reply by ●July 16, 20102010-07-16
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
--- In 6..., "tberkau" wrote:
>
> Hi,
>
> At work we've been migrating our hardware from the MC68HC11A1CFN3 to MC9S12XD256MAG. Everything is working fine, but we're running into a weird issue with one magnetic sensor that cropped up. What's happening is when the pulse accumulator is setup to get pulses from the sensor, it works, but appears to randomly start losing pulses.
>
> Like for example, say I had magnetic data at points x, y, and z. For the first 3-4 times I run something through it'll pick up all three points. Then the next time I run something through it'll suddenly lose point x, and next time it'll be point z that's missing.
>
> I've already tried disabling any unnecessary interrupts or code that could potentially interfere with data collection. I also try adjusting the delay counter to see if that would make a difference which it didn't. Does anyone have any additional ideas of what I could try or what the problem could be? I can provide additional info if needed.
>
Darci
--- In 6..., "tberkau" wrote:
>
> Hi,
>
> At work we've been migrating our hardware from the MC68HC11A1CFN3 to MC9S12XD256MAG. Everything is working fine, but we're running into a weird issue with one magnetic sensor that cropped up. What's happening is when the pulse accumulator is setup to get pulses from the sensor, it works, but appears to randomly start losing pulses.
>
> Like for example, say I had magnetic data at points x, y, and z. For the first 3-4 times I run something through it'll pick up all three points. Then the next time I run something through it'll suddenly lose point x, and next time it'll be point z that's missing.
>
> I've already tried disabling any unnecessary interrupts or code that could potentially interfere with data collection. I also try adjusting the delay counter to see if that would make a difference which it didn't. Does anyone have any additional ideas of what I could try or what the problem could be? I can provide additional info if needed.
>
Reply by ●July 19, 20102010-07-19
--- 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.
>
> 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.
Reply by ●July 19, 20102010-07-19
--- 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.
>
> 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.
Reply by ●July 22, 20102010-07-22
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
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
Reply by ●July 22, 20102010-07-22
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
>
>
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
>
>
Reply by ●July 22, 20102010-07-22
--- 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
>
I apologize, I should've been more clear. Each tick on the graph represents a pulse "event" by the pulse accumulator.
Reply by ●July 22, 20102010-07-22
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.
>
>
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.
>
>
