<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Unused interrupt vectors</title>
	<atom:link href="http://embeddedgurus.com/stack-overflow/2009/04/unused-interrupt-vectors/feed/" rel="self" type="application/rss+xml" />
	<link>http://embeddedgurus.com/stack-overflow/2009/04/unused-interrupt-vectors/</link>
	<description>Thoughts on embedded systems by Nigel Jones</description>
	<lastBuildDate>Thu, 09 Feb 2012 07:32:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: GregK</title>
		<link>http://embeddedgurus.com/stack-overflow/2009/04/unused-interrupt-vectors/comment-page-1/#comment-200</link>
		<dc:creator>GregK</dc:creator>
		<pubDate>Fri, 24 Apr 2009 14:37:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfcdev.org/test-stack/2009/04/19/unused-interrupt-vectors/#comment-200</guid>
		<description>Hi NigelAd.1 In this case I do not have ambition to catch problem what I do not expect and cannot reproduce, it is actually point how to catch something when we already determine which unwanted interrupt occurred by your trap method.Ad.2 Do You mean which source caused  call  this handler? It is not easy I suppose , probably you have to open SFR window in IDE and go through all flags to see which one is set. It is not big effort once every 3years (probably we do not have to do this to often). However IDE always support some kind of signalling which registers changed its value from last refresh so it should not be difficult.Back to Ad.1 There is other way to catch overwritten enable flag register without breakpoints, just set on start up all pending flags for not used interrupts, and before of course clear enable registers for that sources if not by default...  Vice versa should works as well (clear pending flags, enable interrupts).</description>
		<content:encoded><![CDATA[<p>Hi NigelAd.1 In this case I do not have ambition to catch problem what I do not expect and cannot reproduce, it is actually point how to catch something when we already determine which unwanted interrupt occurred by your trap method.Ad.2 Do You mean which source caused  call  this handler? It is not easy I suppose , probably you have to open SFR window in IDE and go through all flags to see which one is set. It is not big effort once every 3years (probably we do not have to do this to often). However IDE always support some kind of signalling which registers changed its value from last refresh so it should not be difficult.Back to Ad.1 There is other way to catch overwritten enable flag register without breakpoints, just set on start up all pending flags for not used interrupts, and before of course clear enable registers for that sources if not by default&#8230;  Vice versa should works as well (clear pending flags, enable interrupts).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel Jones</title>
		<link>http://embeddedgurus.com/stack-overflow/2009/04/unused-interrupt-vectors/comment-page-1/#comment-199</link>
		<dc:creator>Nigel Jones</dc:creator>
		<pubDate>Fri, 24 Apr 2009 11:17:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfcdev.org/test-stack/2009/04/19/unused-interrupt-vectors/#comment-199</guid>
		<description>Hi Greg. I have a couple of problems with what you suggested in point 1.1.It doesn&#039;t solve the problem of an errant pointer being dereferenced and causing the interrupt to be enabled.2.A lot of debuggers have limited break points, so dedicating breakpoints to things that you don&#039;t think are going to happen is rarely done.Regarding the proper compiler. The feature you describe sounds helpful (and it sure beats defining 117 interrupt handlers). Being a default handler though, how difficult is it to determine what tripped it - and thus what the problem is?</description>
		<content:encoded><![CDATA[<p>Hi Greg. I have a couple of problems with what you suggested in point 1.1.It doesn&#8217;t solve the problem of an errant pointer being dereferenced and causing the interrupt to be enabled.2.A lot of debuggers have limited break points, so dedicating breakpoints to things that you don&#8217;t think are going to happen is rarely done.Regarding the proper compiler. The feature you describe sounds helpful (and it sure beats defining 117 interrupt handlers). Being a default handler though, how difficult is it to determine what tripped it &#8211; and thus what the problem is?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: GregK</title>
		<link>http://embeddedgurus.com/stack-overflow/2009/04/unused-interrupt-vectors/comment-page-1/#comment-198</link>
		<dc:creator>GregK</dc:creator>
		<pubDate>Wed, 22 Apr 2009 15:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfcdev.org/test-stack/2009/04/19/unused-interrupt-vectors/#comment-198</guid>
		<description>1. The best way to track why this unwanted interrupt happened (assumed software crashed, it is only reason I can imagine, we can not avoid RF problems ) is simply put a breakpoint on write memory location where interrupt enable flag exist (in our example is address of EIMSK_INT ). If flag is not shared among other flags what you modify during program execution then you are almost at home 2. ‘Proper’ compilers (actually linkers) support “default interrupt”, for example pic24H has 117  interrupts’ sources ... so if we do not assign some of them but we define default interrupt we can trap this in only one place.</description>
		<content:encoded><![CDATA[<p>1. The best way to track why this unwanted interrupt happened (assumed software crashed, it is only reason I can imagine, we can not avoid RF problems ) is simply put a breakpoint on write memory location where interrupt enable flag exist (in our example is address of EIMSK_INT ). If flag is not shared among other flags what you modify during program execution then you are almost at home 2. ‘Proper’ compilers (actually linkers) support “default interrupt”, for example pic24H has 117  interrupts’ sources &#8230; so if we do not assign some of them but we define default interrupt we can trap this in only one place.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

