> Redd, Emmett R writes on 01:15 PM 12/15/2009
>It is really bad programming to not have all interrupt vectors
>assigned to a handler. Axiom appears to have assigned all of them to
>unused_isr which appears to have the address of $c031. It appears
>you do not know what their handler does and I know I don't :-(. But,
>as a good microcontroller programmer, you should know or you should
>write one so you know every possible path your program can take. If
>I ask you what happens if there is a spurious clkmon (or any other)
>interrupt, and you answer, "I don't know," you are not doing your
>job as a microcontroller programmer. :-(
Isn't it equally important to know about and not have "spurious"
interrupts? If the peripheral(s) that use a vector have their
interrupt disabled, the interrupt cannot occur. If you say the
interrupt might get accidentally enabled, then that's the problem to
solve, not installing a handler that masks the symptom. If you say
ESD might cause an interrupt, then the board should be designed to
operate up to and beyond the ESD limits required by the product's
intended market. I would rather a program crash during development so
I can find that I didn't dot the i's and cross the t's in the
initialization or to find ESD problems, than to install a handler
that merely gives the appearance that the hardware is programmed and
running correctly. The do-nothing vectors don't guarantee the system
can't lock up. Program a timer to interrupt faster than the
processor can keep up and the system will hang running the do-nothing
handler forever.
I'm not saying don't install do-nothing vectors, because they might
keep a product operational in an above limit ESD event, as opposed to
crashing. I might suggest the unused handler enable the watchdog for
the shortest period possible, lock up and use a good system reset to
recover. What caused the spurious interrupt (ESD probably) might
also have left the system flaky because RAM was also disturbed.
Bill
>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:
'
'
'
'
''
Re: Hardware vs software interrupt vectors
Started by ●December 15, 2009
Reply by ●December 15, 20092009-12-15
On 2009-December-15, at 6:46 PM, Bill Auerbach wrote:
> >
> Isn't it equally important to know about and not have "spurious"
> interrupts?
>
Absolutely, but computing is equally about handling errors as it is normal processing. The software people have to be able to detect the errors so that the hardware people can harden the system against things like ESD. How do you know that you have an ESD problem, you don't turn off interrupts and throw diodes at the problem or how would you know when to stop? Diodes and capacitors won't detect division by zero, but putting in a trap will.
Nobody is saying that do "nothing vectors" harden the system, they help you identify unexpected behaviours. But not using the features that are given is just ignorant, literally. When you get an unexpected interrupt (since that is what we are talking about) wouldn't it make more sense to save the interrupt information and the stack and halt the system? If the interrupts never get used, they cost nothing.
I think that Professor Redd's suggestion is exactly correct. It helps you detect the problems early, before your customers do. It is a small part of the known best practices and should not be ignored.
To quote a member of this list:
"please don't put your gloom and doom programming rules out on a public forum where beginners may be trying to learn correct programming practices."
> >
> Isn't it equally important to know about and not have "spurious"
> interrupts?
>
Absolutely, but computing is equally about handling errors as it is normal processing. The software people have to be able to detect the errors so that the hardware people can harden the system against things like ESD. How do you know that you have an ESD problem, you don't turn off interrupts and throw diodes at the problem or how would you know when to stop? Diodes and capacitors won't detect division by zero, but putting in a trap will.
Nobody is saying that do "nothing vectors" harden the system, they help you identify unexpected behaviours. But not using the features that are given is just ignorant, literally. When you get an unexpected interrupt (since that is what we are talking about) wouldn't it make more sense to save the interrupt information and the stack and halt the system? If the interrupts never get used, they cost nothing.
I think that Professor Redd's suggestion is exactly correct. It helps you detect the problems early, before your customers do. It is a small part of the known best practices and should not be ignored.
To quote a member of this list:
"please don't put your gloom and doom programming rules out on a public forum where beginners may be trying to learn correct programming practices."
Reply by ●December 16, 20092009-12-16
For development purposes I want to know if anything aberrant happens. But in our
final products it is important that the system recovers from ESD, power
glitches, undiscovered software bugs or whatever. For that reason all unused
vectors do a reset, COP watchdog is used and reset in the main program loop, and
there is a brownout detector that also does a reset. Luckily we don't have
to preserve state (other than configuration/calibration in EEPROM) through a
reset.
Tom Almy
Tualatin, Oregon USA
Internet: t...@almy.us
Website: almy.us
On Dec 15, 2009, at 6:57 PM, Andrei Chichak wrote:
>
> On 2009-December-15, at 6:46 PM, Bill Auerbach wrote:
>
>>>
>> Isn't it equally important to know about and not have "spurious"
>> interrupts?
>>
> Absolutely, but computing is equally about handling errors as it is normal processing. The software people have to be able to detect the errors so that the hardware people can harden the system against things like ESD. How do you know that you have an ESD problem, you don't turn off interrupts and throw diodes at the problem or how would you know when to stop? Diodes and capacitors won't detect division by zero, but putting in a trap will.
Tom Almy
Tualatin, Oregon USA
Internet: t...@almy.us
Website: almy.us
On Dec 15, 2009, at 6:57 PM, Andrei Chichak wrote:
>
> On 2009-December-15, at 6:46 PM, Bill Auerbach wrote:
>
>>>
>> Isn't it equally important to know about and not have "spurious"
>> interrupts?
>>
> Absolutely, but computing is equally about handling errors as it is normal processing. The software people have to be able to detect the errors so that the hardware people can harden the system against things like ESD. How do you know that you have an ESD problem, you don't turn off interrupts and throw diodes at the problem or how would you know when to stop? Diodes and capacitors won't detect division by zero, but putting in a trap will.
Reply by ●December 16, 20092009-12-16
> Andrei Chichak writes on 09:57 PM 12/15/2009
>Absolutely, but computing is equally about handling errors as it is
>normal processing. The software people have to be able to detect the
>errors so that the hardware people can harden the system against
>things like ESD. How do you know that you have an ESD problem, you
>don't turn off interrupts and throw diodes at the problem or how
>would you know when to stop? Diodes and capacitors won't detect
>division by zero, but putting in a trap will.
A divide by error isn't a spurious interrupt, it's a programming
problem. If you enable divide by 0 interrupts, your software should
be preventing the divide by 0, not using the trap to handle them.
What are you going to do in the handler? This is something that
should have been considered at the time of the divide.
>Nobody is saying that do "nothing vectors" harden the system, they
>help you identify unexpected behaviours. But not using the features
>that are given is just ignorant, literally. When you get an
>unexpected interrupt (since that is what we are talking about)
>wouldn't it make more sense to save the interrupt information and
>the stack and halt the system? If the interrupts never get used,
>they cost nothing.
What features did I say not to use? Filling vectors for peripherals
that are not used serves what purpose? And I didn't say not to use
them and I didn't say anyone said using them do harden it. Did you
read the email or have you been sitting back just waiting to snipe at
me because I corrected you in a post, umm, months ago? I mentioned
why releasing a product with them in isn't a bad thing, and also
mentioned, as another reader has confirmed, that they can be used to
better recover from an ESD event.
How do do-nothing vectors identify unexpected behavior? If they
do-nothing and return, they didn't detect anything.
>I think that Professor Redd's suggestion is exactly correct. It
>helps you detect the problems early, before your customers do. It is
>a small part of the known best practices and should not be ignored.
I didn't say he wasn't correct - you've adding that my post said that
which is incorrect. My suggestion was to detect problems - I don't
use the vectors when developing to know I'll catch a problem which
might just be an oversight in initializing. I don't enable
interrupts on peripherals I'm not using. Why is a vector for that
peripheral helpful? You mention divide by 0 - that's not a spurious
interrupt, it would be a programmer error to have allowed it. You're
just looking for something to fire back at me for. I didn't say not
using vectors wasn't correct, I asked why is it necessary, and also,
if you do use them, there may be a better way to handle them.
>To quote a member of this list:
>"please don't put your gloom and doom programming rules out on a
>public forum where beginners may be trying to learn correct
>programming practices."
Being professional is also a good practice. I corrected a post of
yours that was dead-wrong - and asked you to back it up and you
provided no substance to back up what you said. Here, I'm trying to
add information, which isn't wrong, based on extensive embedded
programming experiences in developing several high-reliable
products. Our products passed ESD 2-5 times CE requirements and
spurious interrupts on unused peripherals were never the
problem. Interrupts on used peripherals were if you're interested in
discussing real-world topics.
Bill
>Absolutely, but computing is equally about handling errors as it is
>normal processing. The software people have to be able to detect the
>errors so that the hardware people can harden the system against
>things like ESD. How do you know that you have an ESD problem, you
>don't turn off interrupts and throw diodes at the problem or how
>would you know when to stop? Diodes and capacitors won't detect
>division by zero, but putting in a trap will.
A divide by error isn't a spurious interrupt, it's a programming
problem. If you enable divide by 0 interrupts, your software should
be preventing the divide by 0, not using the trap to handle them.
What are you going to do in the handler? This is something that
should have been considered at the time of the divide.
>Nobody is saying that do "nothing vectors" harden the system, they
>help you identify unexpected behaviours. But not using the features
>that are given is just ignorant, literally. When you get an
>unexpected interrupt (since that is what we are talking about)
>wouldn't it make more sense to save the interrupt information and
>the stack and halt the system? If the interrupts never get used,
>they cost nothing.
What features did I say not to use? Filling vectors for peripherals
that are not used serves what purpose? And I didn't say not to use
them and I didn't say anyone said using them do harden it. Did you
read the email or have you been sitting back just waiting to snipe at
me because I corrected you in a post, umm, months ago? I mentioned
why releasing a product with them in isn't a bad thing, and also
mentioned, as another reader has confirmed, that they can be used to
better recover from an ESD event.
How do do-nothing vectors identify unexpected behavior? If they
do-nothing and return, they didn't detect anything.
>I think that Professor Redd's suggestion is exactly correct. It
>helps you detect the problems early, before your customers do. It is
>a small part of the known best practices and should not be ignored.
I didn't say he wasn't correct - you've adding that my post said that
which is incorrect. My suggestion was to detect problems - I don't
use the vectors when developing to know I'll catch a problem which
might just be an oversight in initializing. I don't enable
interrupts on peripherals I'm not using. Why is a vector for that
peripheral helpful? You mention divide by 0 - that's not a spurious
interrupt, it would be a programmer error to have allowed it. You're
just looking for something to fire back at me for. I didn't say not
using vectors wasn't correct, I asked why is it necessary, and also,
if you do use them, there may be a better way to handle them.
>To quote a member of this list:
>"please don't put your gloom and doom programming rules out on a
>public forum where beginners may be trying to learn correct
>programming practices."
Being professional is also a good practice. I corrected a post of
yours that was dead-wrong - and asked you to back it up and you
provided no substance to back up what you said. Here, I'm trying to
add information, which isn't wrong, based on extensive embedded
programming experiences in developing several high-reliable
products. Our products passed ESD 2-5 times CE requirements and
spurious interrupts on unused peripherals were never the
problem. Interrupts on used peripherals were if you're interested in
discussing real-world topics.
Bill
Reply by ●December 16, 20092009-12-16
>
> Being professional is also a good practice. I corrected a post of
> yours that was dead-wrong - and asked you to back it up and you
> provided no substance to back up what you said. .
>
>
>
See Hatton, L. (1995), Safer C, McGraw-Hill. Section 2.8.3 "Arrays are not always synonymous with pointers"
Dead wrong? My products have gone through Health Canada and the FDA. If I'm dead wrong I get to take people's grandmothers with me.
> Being professional is also a good practice. I corrected a post of
> yours that was dead-wrong - and asked you to back it up and you
> provided no substance to back up what you said. .
>
>
>
See Hatton, L. (1995), Safer C, McGraw-Hill. Section 2.8.3 "Arrays are not always synonymous with pointers"
Dead wrong? My products have gone through Health Canada and the FDA. If I'm dead wrong I get to take people's grandmothers with me.
Reply by ●December 16, 20092009-12-16
Hey! You two settle down, or we'll turn the car around right now! :)
All of you raise very good points, and listening to all this makes me want to go back to college, and surround myself with big brains like the people on this forum!
I work as an electronics technician, so my co-workers, many times, have no idea what I'm talking about when it comes to programming or engineering issues.
OK, help me out Bill, or somebody, by ESD, you must mean electro static discharge? What type of ESD testing do you put the product through? Surely, it must be a loose coupled test if it is electro static discharge.
ESD pulses of a certain kilovolt range are produced in close proximity to the product, and the accompanying EMP is what the product must have resistance to?
Jerry
To: 6...
From: g...@chichak.ca
Date: Tue, 15 Dec 2009 23:00:05 -0700
Subject: Re: [68HC12] Hardware vs software interrupt vectors
>
> Being professional is also a good practice. I corrected a post of
> yours that was dead-wrong - and asked you to back it up and you
> provided no substance to back up what you said. .
>
>
>
See Hatton, L. (1995), Safer C, McGraw-Hill. Section 2.8.3 "Arrays are not always synonymous with pointers"
Dead wrong? My products have gone through Health Canada and the FDA. If I'm dead wrong I get to take people's grandmothers with me.
_________________________________________________________________
Hotmail: Trusted email with Microsofts powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
Reply by ●December 18, 20092009-12-18
Jerry,
> Jerry Fields writes on 09:27 AM 12/16/2009
>OK, help me out Bill, or somebody, by ESD, you must mean electro
>static discharge?
Yes.
> What type of ESD testing do you put the product through? Surely,
> it must be a loose coupled test if it is electro static discharge.
CE and/or FCC product compliance requires, among other things,
immunity to contact and non-contact (air) discharges. ESD. CE
requirement are on the low side - 4kV (+ and -) for contact 8kV (+/-)
for non-contact. The device must survive, not have any detriment
side effect, or lock up. It is permissible to reset providing doing
so isn't detrimental. To ensure we passed CE, we tested products to
8kV contact and 30kV non-contact. We tested in 1kV increments
hitting dozens of test points on the product. It can take a couple
of days. One device was battery powered which was more difficult
because 1) There was no power ground and 2) In sleep mode it was
drawing about 8uA (in the area of battery shelf discharge levels) and
the test would wake it up. Sometimes it wouldn't go back to sleep
and we considered this a failure mode. ESD would cause multiple and
glitch-like interrupts which we had to handle. All of our I/O was
well protected. We did have firmware changes to prevent crashes and
not going to sleep but we worked it all out. We did have a couple of
board changes to add better protection or change the board layout.
>ESD pulses of a certain kilovolt range are produced in close
>proximity to the product, and the accompanying EMP is what the
>product must have resistance to?
Yes, essentially. They also like to test all suspect points, even
places where the discharge can pass through the case and hit the
PCB. We had problems with a keypad because that discharged right
into the processor inputs. The battery powered product was tough
without a power ground, or grounded by how and where it was mounted,
or in fact no ground at all.
All of our products passed on the first submission, which is
important because it's not inexpensive to test each product. It pays
to test up front and well over the minimum requirements.
Bill
> Jerry Fields writes on 09:27 AM 12/16/2009
>OK, help me out Bill, or somebody, by ESD, you must mean electro
>static discharge?
Yes.
> What type of ESD testing do you put the product through? Surely,
> it must be a loose coupled test if it is electro static discharge.
CE and/or FCC product compliance requires, among other things,
immunity to contact and non-contact (air) discharges. ESD. CE
requirement are on the low side - 4kV (+ and -) for contact 8kV (+/-)
for non-contact. The device must survive, not have any detriment
side effect, or lock up. It is permissible to reset providing doing
so isn't detrimental. To ensure we passed CE, we tested products to
8kV contact and 30kV non-contact. We tested in 1kV increments
hitting dozens of test points on the product. It can take a couple
of days. One device was battery powered which was more difficult
because 1) There was no power ground and 2) In sleep mode it was
drawing about 8uA (in the area of battery shelf discharge levels) and
the test would wake it up. Sometimes it wouldn't go back to sleep
and we considered this a failure mode. ESD would cause multiple and
glitch-like interrupts which we had to handle. All of our I/O was
well protected. We did have firmware changes to prevent crashes and
not going to sleep but we worked it all out. We did have a couple of
board changes to add better protection or change the board layout.
>ESD pulses of a certain kilovolt range are produced in close
>proximity to the product, and the accompanying EMP is what the
>product must have resistance to?
Yes, essentially. They also like to test all suspect points, even
places where the discharge can pass through the case and hit the
PCB. We had problems with a keypad because that discharged right
into the processor inputs. The battery powered product was tough
without a power ground, or grounded by how and where it was mounted,
or in fact no ground at all.
All of our products passed on the first submission, which is
important because it's not inexpensive to test each product. It pays
to test up front and well over the minimum requirements.
Bill
Reply by ●December 18, 20092009-12-18
Thanks Bill! I find all of that extremely interesting! I need to find a
electrical engineering forum too!
When it comes to the loose coupled effects of the ESD (EMP), its the rising and falling edges that are damaging to the circuit. Correct? I imagine, that the over all frequencies of ESDs can vary, so the impedance of the protection devices would be designed to pass or block the frequencies of the rising and falling edges of the pulse. (i.e. several hundred Meg to around a gig.) Yes?
Am I on track with that thought?
To: 6...
From: b...@softools.com
Date: Thu, 17 Dec 2009 23:04:09 -0500
Subject: RE: [68HC12] Hardware vs software interrupt vectors
Jerry,
> Jerry Fields writes on 09:27 AM 12/16/2009
>OK, help me out Bill, or somebody, by ESD, you must mean electro
>static discharge?
Yes.
> What type of ESD testing do you put the product through? Surely,
> it must be a loose coupled test if it is electro static discharge.
CE and/or FCC product compliance requires, among other things,
immunity to contact and non-contact (air) discharges. ESD. CE
requirement are on the low side - 4kV (+ and -) for contact 8kV (+/-)
for non-contact. The device must survive, not have any detriment
side effect, or lock up. It is permissible to reset providing doing
so isn't detrimental. To ensure we passed CE, we tested products to
8kV contact and 30kV non-contact. We tested in 1kV increments
hitting dozens of test points on the product. It can take a couple
of days. One device was battery powered which was more difficult
because 1) There was no power ground and 2) In sleep mode it was
drawing about 8uA (in the area of battery shelf discharge levels) and
the test would wake it up. Sometimes it wouldn't go back to sleep
and we considered this a failure mode. ESD would cause multiple and
glitch-like interrupts which we had to handle. All of our I/O was
well protected. We did have firmware changes to prevent crashes and
not going to sleep but we worked it all out. We did have a couple of
board changes to add better protection or change the board layout.
>ESD pulses of a certain kilovolt range are produced in close
>proximity to the product, and the accompanying EMP is what the
>product must have resistance to?
Yes, essentially. They also like to test all suspect points, even
places where the discharge can pass through the case and hit the
PCB. We had problems with a keypad because that discharged right
into the processor inputs. The battery powered product was tough
without a power ground, or grounded by how and where it was mounted,
or in fact no ground at all.
All of our products passed on the first submission, which is
important because it's not inexpensive to test each product. It pays
to test up front and well over the minimum requirements.
Bill
_________________________________________________________________
Hotmail: Trusted email with Microsofts powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
When it comes to the loose coupled effects of the ESD (EMP), its the rising and falling edges that are damaging to the circuit. Correct? I imagine, that the over all frequencies of ESDs can vary, so the impedance of the protection devices would be designed to pass or block the frequencies of the rising and falling edges of the pulse. (i.e. several hundred Meg to around a gig.) Yes?
Am I on track with that thought?
To: 6...
From: b...@softools.com
Date: Thu, 17 Dec 2009 23:04:09 -0500
Subject: RE: [68HC12] Hardware vs software interrupt vectors
Jerry,
> Jerry Fields writes on 09:27 AM 12/16/2009
>OK, help me out Bill, or somebody, by ESD, you must mean electro
>static discharge?
Yes.
> What type of ESD testing do you put the product through? Surely,
> it must be a loose coupled test if it is electro static discharge.
CE and/or FCC product compliance requires, among other things,
immunity to contact and non-contact (air) discharges. ESD. CE
requirement are on the low side - 4kV (+ and -) for contact 8kV (+/-)
for non-contact. The device must survive, not have any detriment
side effect, or lock up. It is permissible to reset providing doing
so isn't detrimental. To ensure we passed CE, we tested products to
8kV contact and 30kV non-contact. We tested in 1kV increments
hitting dozens of test points on the product. It can take a couple
of days. One device was battery powered which was more difficult
because 1) There was no power ground and 2) In sleep mode it was
drawing about 8uA (in the area of battery shelf discharge levels) and
the test would wake it up. Sometimes it wouldn't go back to sleep
and we considered this a failure mode. ESD would cause multiple and
glitch-like interrupts which we had to handle. All of our I/O was
well protected. We did have firmware changes to prevent crashes and
not going to sleep but we worked it all out. We did have a couple of
board changes to add better protection or change the board layout.
>ESD pulses of a certain kilovolt range are produced in close
>proximity to the product, and the accompanying EMP is what the
>product must have resistance to?
Yes, essentially. They also like to test all suspect points, even
places where the discharge can pass through the case and hit the
PCB. We had problems with a keypad because that discharged right
into the processor inputs. The battery powered product was tough
without a power ground, or grounded by how and where it was mounted,
or in fact no ground at all.
All of our products passed on the first submission, which is
important because it's not inexpensive to test each product. It pays
to test up front and well over the minimum requirements.
Bill
_________________________________________________________________
Hotmail: Trusted email with Microsofts powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
Reply by ●December 29, 20092009-12-29
> Jerry Fields writes on 12:33 PM 12/18/2009
>Thanks Bill! I find all of that extremely interesting! I need to
>find a electrical engineering forum too!
You're welcome Jerry.
>When it comes to the loose coupled effects of the ESD (EMP), its the
>rising and falling edges that are damaging to the circuit. Correct?
>I imagine, that the over all frequencies of ESDs can vary, so the
>impedance of the protection devices would be designed to pass or
>block the frequencies of the rising and falling edges of the pulse.
>(i.e. several hundred Meg to around a gig.) Yes?
I'm not an expert on the electrical test damage or effects. Since I
had to sign the PO's for the outside testing done by my group, I had
to know what internal tests were done and if we were confident we
would pass on the first submission. We never got into IC failure
modes. Although through the several hundred zaps on 12 PC boards we
never saw any IC fail.
>Am I on track with that thought?
I can't say, except it sounds on track. If you find an expert on
this and can provide failure analysis and causes, please report back.
Happy New Year!
Bill
>Thanks Bill! I find all of that extremely interesting! I need to
>find a electrical engineering forum too!
You're welcome Jerry.
>When it comes to the loose coupled effects of the ESD (EMP), its the
>rising and falling edges that are damaging to the circuit. Correct?
>I imagine, that the over all frequencies of ESDs can vary, so the
>impedance of the protection devices would be designed to pass or
>block the frequencies of the rising and falling edges of the pulse.
>(i.e. several hundred Meg to around a gig.) Yes?
I'm not an expert on the electrical test damage or effects. Since I
had to sign the PO's for the outside testing done by my group, I had
to know what internal tests were done and if we were confident we
would pass on the first submission. We never got into IC failure
modes. Although through the several hundred zaps on 12 PC boards we
never saw any IC fail.
>Am I on track with that thought?
I can't say, except it sounds on track. If you find an expert on
this and can provide failure analysis and causes, please report back.
Happy New Year!
Bill
Reply by ●December 30, 20092009-12-30
Hi Group,
I have a couple ofquestions aboutthe HC12 controller.
1) Can we connect a cell phone to HC 12 controller
2) Then pass command back and forth between the cell phone and HC12
3) Has any one done a project in which you can pass a message to a cell phone connected to the HC 12 controller and depending on the message or number the output of the controller will be a 0 0r 1.
Any information on the above related questing will be greatly appreciated.
Thanks!
Mahesh Suddhala
I have a couple ofquestions aboutthe HC12 controller.
1) Can we connect a cell phone to HC 12 controller
2) Then pass command back and forth between the cell phone and HC12
3) Has any one done a project in which you can pass a message to a cell phone connected to the HC 12 controller and depending on the message or number the output of the controller will be a 0 0r 1.
Any information on the above related questing will be greatly appreciated.
Thanks!
Mahesh Suddhala
