<?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>Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/24507/branch-to-main-fails-ends-up-in-swi-handler</link><description> 
I have a project that works until I add in some C modules that I
inherited from someone else. The startup code (sam7.s) is the default
startup code supplied by KEIL for the ATMEL AT91SAM7S256 (for MDK ARM
V3.22a). The problem is that when the startup</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/135638?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 22:22:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e874d283-235d-4e40-a850-e45d82ebecbc</guid><dc:creator>Franc  Urbanc</dc:creator><description>&lt;p&gt;&lt;p&gt;
If you are not using a file IO in your application, you should
consider using a &lt;b&gt;microlib&lt;/b&gt;. The microlib does not support
semihosting and therefore you do not need a &lt;i&gt;retarget.c&lt;/i&gt;. The
builded executable image is smaller and with some limitations, but
more suitable for small embedded projects.&lt;/p&gt;

&lt;p&gt;
The standard runtime library is build for the underlying Operating
System. All the system calls are coded as SWI&amp;#39;s. For example a simple
putchar function executes a SWI and activates a low level putchar
function from the operating system. If you do not have one, you have
to redirect the low level to your own implementation of these
functions (in &lt;i&gt;regarget.c&lt;/i&gt;). In this case you have to tell the
linker not to use the semihosting interface with:&lt;/p&gt;

&lt;pre&gt;
#pragma import(__use_no_semihosting_swi)
&lt;/pre&gt;

&lt;p&gt;
Franc&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/125158?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 15:56:15 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6779019e-e825-4907-84e4-66bda654b1de</guid><dc:creator>Dave Sudolcan</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks so much Robert!&lt;/p&gt;

&lt;p&gt;
Adding the right include file (rt_sys.h) to get the definition of
FILEHANDLE before including the functions you provided has fixed the
problem. I can finally get to the main function and continue with
regular development/debugging.&lt;/p&gt;

&lt;p&gt;
Of course... now I&amp;#39;ve got to spend a little time analyzing this
problem and your solution to get a better handle on what went wrong
in the first place. The obvious place to start is the __main function
(that I incorrectly thought was the C main function). My guess is
that C startup stuff is in a KEIL library (hence, the IMPORT __main
statement). If so, where&amp;#39;s that source code? Is it published?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/114563?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 15:23:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5ee396d5-1b86-4d59-ad10-4ad7c9c02534</guid><dc:creator>Robert McNamara</dc:creator><description>&lt;p&gt;&lt;p&gt;
The __main is NOT your main. This does all the C initialization. I
still suspect that you are having a retarget.c problem&lt;/p&gt;

&lt;p&gt;
You will need to add something like...&lt;/p&gt;

&lt;pre&gt;
void _ttywrch (int ch) {
  return;
}

FILEHANDLE _sys_open (const char *name, int openmode)
{
    return 0;
}

&lt;/pre&gt;

&lt;p&gt;
to retarget.c&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/114550?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 15:18:15 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:076c20fb-ce53-4e7f-b7e3-98d7bf9eca33</guid><dc:creator>Dave Sudolcan</dc:creator><description>&lt;p&gt;&lt;p&gt;
The code I inherited does do dynamic memory allocation (associated
with file transfers across an EtherCAT network). I plan to eventually
rewrite it so it doesn&amp;#39;t. But for now... it does.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/102927?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 15:15:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:257dd3b0-3b95-468c-b914-36b81716b4bf</guid><dc:creator>Dave Sudolcan</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for the tip Robert.&lt;/p&gt;

&lt;p&gt;
I was not including a retarget.c file in my project, so I did a
quick file search of my C:\KEIL\ARM directory and found quite a few
to pick from. I looked at several for an ATMEL AT91SAM uC, and added
the simplest one to my project to see what would happen. Here&amp;#39;s what
was in that file:&lt;/p&gt;

&lt;pre&gt;
#include &amp;lt;rt_misc.h&amp;gt;

#pragma import(__use_no_semihosting_swi)

void _sys_exit(int return_code) {
label:  goto label;  /* endless loop */
}
&lt;/pre&gt;

&lt;p&gt;
Now my project won&amp;#39;t build (without errors) anymore. Apparently,
the _sys_open and _ttywrch functions are being used somehow, although
I can find no reference to them in any of my project files. I don&amp;#39;t
call printf, puts, scanf, or anything like that (aren&amp;#39;t those the
type of things that would fall under the &amp;quot;semihosting&amp;quot; category?); so
I don&amp;#39;t know why or where _sys_open or _ttywrch would be being
called.&lt;/p&gt;

&lt;p&gt;
Besides... the right address for __main is in R0 when the BX R0
instruction is executed, so how could the uC not then branch to that
address...? That code happens before any C code is executed. This
problem (as best as I can tell) occurs whether I&amp;#39;m executing code
from the debugger or not.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m stumped!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/101483?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 15:06:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:457b5343-95f4-46be-a97c-e04a3df8e25e</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
You only reserve memory for a heap if you do dynamic memory
allocations from said heap.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/77005?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 13:58:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c0f3ea72-23de-4c32-85f4-21c6fdd4ae68</guid><dc:creator>Robet McNamara</dc:creator><description>&lt;p&gt;&lt;p&gt;
I would make sure you have include retarget.c in your project
(look at examples if you have not). It is possible that the stdio
system was initialized after including the other code and it was not
initialized in your code.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Branch to main fails (ends up in SWI handler)</title><link>https://community.arm.com/thread/53149?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2008 13:46:00 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:40f43c44-6c5c-4cca-8d25-a8af052cec33</guid><dc:creator>Dave Sudolcan</dc:creator><description>&lt;p&gt;&lt;p&gt;
P.S., I did find some references in the online knowledgebase to
reserving space for the heap should this problem occur, and have
reserved 0x8000 bytes for the heap, but that has had no effect on the
symptom. Since this is a &amp;#39;C&amp;#39;/ASM project (i.e., no C++ code), and no
&amp;#39;C&amp;#39; code could&amp;#39;ve been run yet (since the program hasn&amp;#39;t made it to
&amp;#39;main&amp;#39; yet), I&amp;#39;m not sure how not reserving space for the heap
could&amp;#39;ve caused this symptom either. Can anyone explain how not
reserving space for the heap could cause this problem?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>