<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/38475/at89c51-adc-in-timer-interrupt-problem</link><description> 
Hi there, 

 
This may be a compiler/driver issue or it may be a hardware issue
but I am wondering if anyone else has seen a similar problem to
this. 

 
We have code to read an ADC channel and this works fine. We have
code to generate timer interrupts</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/thread/77679?ContentTypeID=1</link><pubDate>Tue, 18 Aug 2009 08:35:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6baec3c5-8086-4aa6-a8b0-3a5e5d74d299</guid><dc:creator>Dirk Veramaak</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;b&gt;SOLVED!!!!&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
Thanks for the help guys but I have now solved the mystery. It was
caused by another read of the ADC from some old part of the code that
I inherited. Eventually the two collided (sort of as Stephan
mentioned).&lt;/p&gt;

&lt;p&gt;
I guess this is always a problem of inheriting code and having to
bind in new devices.&lt;/p&gt;

&lt;p&gt;
I still have no idea why this screwed the CAN up but I guess it
was that the EOC of the ADC was missed or something and that the code
just started missing things. Anyway, it just required including the
extra read of the ADC into the timer loop and hey presto, problem
gone.&lt;/p&gt;

&lt;p&gt;
Cheers for the help.&lt;/p&gt;

&lt;p&gt;
Dirk&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/thread/115166?ContentTypeID=1</link><pubDate>Tue, 18 Aug 2009 08:14:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e981c6a8-ce4c-4895-a5ec-bdcde19f5059</guid><dc:creator>Dirk Veramaak</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks Stephen,&lt;/p&gt;

&lt;p&gt;
However I don&amp;#39;t think this applies here. We only call the ADC read
function once, and this is from inside the timer interrupt. I have
called it from other places to test if it works in those situations
and also in other products it is called outside of the timer.&lt;/p&gt;

&lt;p&gt;
As the Kiel and the 89C51 are not the best at multi threaded
operation we avoid it completely and don&amp;#39;t allow multiple calls as
you pointed out.&lt;/p&gt;

&lt;p&gt;
As it is at the moment I am not even bothering with the data read
form the ADC as I want to crack as to why even accessing the ADC
screws the CAN up.&lt;/p&gt;

&lt;p&gt;
Anyway, thanks for the interest. Any help is appreciated.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/thread/103351?ContentTypeID=1</link><pubDate>Tue, 18 Aug 2009 08:04:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9aded0cf-2a71-4d9b-9212-87a687bd8580</guid><dc:creator>stephen phillips</dc:creator><description>&lt;p&gt;&lt;p&gt;
It is unwise to make function calls from an interrupt to code that
is used outside the interrupt. They are likely to use separate stack
space last I checked. These are CO Routines you need to consider the
PC term &amp;quot;thread safe&amp;quot; you should call only functions in the interrupt
that are used only by the interrupt. Data is the only thing to
consider outside them. Even then the data should only be accessed
when a semaphore is set.&lt;/p&gt;

&lt;p&gt;
Stephen&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/thread/77677?ContentTypeID=1</link><pubDate>Tue, 18 Aug 2009 07:24:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b5f9640d-e779-4d6e-86b1-878dd6feb881</guid><dc:creator>Dirk Veramaak</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for the ideas but I have already been down most of
these.&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;1. Register bank issues.&lt;/b&gt;&lt;br /&gt;
Using the Kiel default, all non-interupts are on 0. I have two timers
on 1 &amp;amp; 2 and the CAN interrupt on 2 also. I have moved the call
to the ADC between the two timer interrupts and the behaviour is the
same.&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;2. Priorities&lt;/b&gt;&lt;br /&gt;
These are default and I can&amp;#39;t see any reason to change them in that
they are correct for what I want them to do. Using a DSO I have
traced the times in and out of the timer interupts and they don&amp;#39;t
clash, I have even altered the periods so they are slightly different
and hence &amp;quot;drift&amp;quot; apart.&lt;/p&gt;

&lt;p&gt;
The very odd thing here is that we have used more or less all this
code in quite a few projects and have never had a problem like this.
It looks more and more like a hardware problem but I know from
experience that it&amp;#39;s very rare that you actually find a real hardware
problem.&lt;/p&gt;

&lt;p&gt;
Cheers,&lt;/p&gt;

&lt;p&gt;
Dirk&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/thread/56636?ContentTypeID=1</link><pubDate>Tue, 18 Aug 2009 07:19:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a2159f11-d91a-4d5e-830b-6ff5c2c11423</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Before I post lots of code as each system is quite
complex,&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
One thing you should do is reduce the code to the minimum
necessary to duplicate the problem. Start a new project and remove
everything that isn&amp;#39;t necessary. This will make it much easier for
you (or someone on this board, if you decide to post the code) to
spot where the problem is.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89C51 ADC in Timer Interrupt Problem</title><link>https://community.arm.com/thread/56627?ContentTypeID=1</link><pubDate>Tue, 18 Aug 2009 07:06:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c300567b-08eb-42f6-adde-adfc3c5d73bd</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;However, when we call the ADC channel read from inside a timer
interrupt (timer1, specially used just for this) it appears to
completely screw up the CAN transmission. We get transmission on odd
channels, bad data, all sorts.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I can only guess, but here&amp;#39;s a few potential problems I would
check for:&lt;/p&gt;

&lt;p&gt;
1. Register bank issues. Do the ISR and the function to read the
the ADC channel use the same memory bank? If there&amp;#39;s a problem here,
the call could corrupt registers for other parts of the program.&lt;/p&gt;

&lt;p&gt;
2. ISR priority issues. What other ISRs are there, and what
priorities do they have?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Even with the ADC read in the interrupt it only occupies 2% of
the processor time so I don&amp;#39;t think it&amp;#39;s to do with load or
latency.&lt;/i&gt; &amp;lt;p&amp;gt;&lt;/p&gt;

&lt;p&gt;
3. Maybe it occupies those 2% at times when it shouldn&amp;#39;t be
occupying them.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>