<?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>install dara abort ISR</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/21365/install-dara-abort-isr</link><description> 
Hello again, 

 
I&amp;#39;m working with the AT91RM9200 controller. How is it possible to
get a printf() message over the usart1 if a dara abort or undefined
instruction has occured? 

 
I&amp;#39;ve one .c file with all ISR; for example: 

 
void AT91F_DataAbort</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: install dara abort ISR</title><link>https://community.arm.com/thread/124223?ContentTypeID=1</link><pubDate>Mon, 12 Nov 2007 14:48:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7f2acf24-14cb-4baf-aeec-d3ee5e7da643</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The &amp;quot;best&amp;quot; solution &amp;quot;may&amp;quot; be to have some variables that survives
a reboot. Let the data abort exception record the most important
register information (where and why). Then perform a reset and
restart the application.&lt;/p&gt;

&lt;p&gt;
If you do have any data that survives a reset, your main() app can
then check if it was a normal reset, or the result of a data abort.
In case of a data abort, you may log info to a serial port, write
down a note to flash file system, ... before resuming the normal
operation.&lt;/p&gt;

&lt;p&gt;
If your app isn&amp;#39;t controlling a nuclear facility, and you get on
average one data abort/year, you might possibly ignore it. If you get
too many in relation to your reliability requirements, you may
retrieve information from your unit(s) and hunt down what is
wrong.&lt;/p&gt;

&lt;p&gt;
One of the problems you have, is that you don&amp;#39;t know how stable
your processor is when it reaches the data abort exception. A
sprintf() buffer overflow may have made all *printf() completely
unreliable.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: install dara abort ISR</title><link>https://community.arm.com/thread/113386?ContentTypeID=1</link><pubDate>Mon, 12 Nov 2007 13:06:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:da18170e-7d56-489e-8024-88ea2b967bd1</guid><dc:creator>Robert McNamara</dc:creator><description>&lt;p&gt;&lt;pre&gt;

                IMPORT AT91F_DataAbort

Vectors         LDR     PC,Reset_Addr
                LDR     PC,Undef_Addr
                LDR     PC,SWI_Addr
                LDR     PC,PAbt_Addr
                LDR     PC,DAbt_Addr
                DCD     0
                LCR     PC,IRQ_Addr
.
.
DAbt_Addr       DCD     AT91F_DataAbort
.
.
&lt;/pre&gt;

&lt;p&gt;
This will call YOUR C function AT91F_DataAbort when a data abort
happens.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: install dara abort ISR</title><link>https://community.arm.com/thread/99917?ContentTypeID=1</link><pubDate>Mon, 12 Nov 2007 12:44:55 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:da6a8241-fd1f-4f32-b58f-ccc075f7a8ef</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;you&amp;#39;re right, but what happened if a data abort
occured???&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The debugger you have connected to the JTAG debug port of your ARM
MCU kicks in and you get to do some detective work. No amount of
printf()ing can possibly be more helpful than that.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: install dara abort ISR</title><link>https://community.arm.com/thread/75700?ContentTypeID=1</link><pubDate>Mon, 12 Nov 2007 11:17:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:711e7fbb-4430-4234-9793-ec548b2440cf</guid><dc:creator>Johannes meier</dc:creator><description>&lt;p&gt;&lt;p&gt;
you&amp;#39;re right, but what happened if a data abort occured??? -
nothing... so the ISR is the last thing and so I only want to get a
message over the usart that such a data abort occured... that&amp;#39;s all.
Atmel do the same in the code examples (but they use a different
startup code - so I don&amp;#39;t know what I had to change to get the same
result...&lt;/p&gt;

&lt;p&gt;
Johannes&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: install dara abort ISR</title><link>https://community.arm.com/thread/48942?ContentTypeID=1</link><pubDate>Mon, 12 Nov 2007 11:07:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d04417fe-7af8-4544-9b41-1be08774cd06</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;How is it possible to get a printf() message over the usart1 if
a dara abort or undefined instruction has occured?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
printf() is just about the last function you should even think of
calling from an ISR. Roughly said, anything beyond a simple putc() or
two would be madness.&lt;/p&gt;

&lt;p&gt;
Catastrophic exceptions like those have to be avoided, not
decorated.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>