<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="bbPress/1.0.2" -->
<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">
	<channel>
		<title>LeafLabs Garden &#187; Topic: libmaple - Interrupt vector problem</title>
		<link>http://forums.leaflabs.com/topic.php?id=1274</link>
		<description>A place to share, learn, and grow...</description>
		<language>en-US</language>
		<pubDate>Fri, 22 Jan 2016 00:14:38 +0000</pubDate>
		<generator>http://bbpress.org/?v=1.0.2</generator>
		<textInput>
			<title><![CDATA[Search]]></title>
			<description><![CDATA[Search all topics from these forums.]]></description>
			<name>q</name>
			<link>http://forums.leaflabs.com/search.php</link>
		</textInput>
		<atom:link href="http://forums.leaflabs.com/rss.php?topic=1274" rel="self" type="application/rss+xml" />

		<item>
			<title>r1s3n on "libmaple - Interrupt vector problem"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1274#post-7784</link>
			<pubDate>Wed, 18 Jan 2012 22:53:25 +0000</pubDate>
			<dc:creator>r1s3n</dc:creator>
			<guid isPermaLink="false">7784@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Well, since only the high density devices have UART4/5 your problem and mine may have been the same.  The interrupts for those 2 uarts aren't included unless the define is passed to the assembler when the libcs3 is built.  Hopefully with the bug report they'll look at fixing it in some way for the next release.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>x893 on "libmaple - Interrupt vector problem"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1274#post-7772</link>
			<pubDate>Wed, 18 Jan 2012 15:02:58 +0000</pubDate>
			<dc:creator>x893</dc:creator>
			<guid isPermaLink="false">7772@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;I write about error in makefile for build libcs3... for UART4. But maple team ignore it last year. easy make local correct version on lib from libmaple source (with corrected makefile)
&#60;/p&#62;</description>
		</item>
		<item>
			<title>r1s3n on "libmaple - Interrupt vector problem"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1274#post-7769</link>
			<pubDate>Wed, 18 Jan 2012 13:50:28 +0000</pubDate>
			<dc:creator>r1s3n</dc:creator>
			<guid isPermaLink="false">7769@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Since no one has replied I did some more digging and managed to solve the problem.  I haven't tested on the hardware yet, but the results are promising.  The problem apparently lies in the libcs3_stm32_[high&#124;med]_density.a files.  As shipped with libmaple, they're identical in size and a quick grep shows that both are missing symbols for the __tim8* irqs which are needed on the high density devices.  I've submitted a bug on the code.google.com site for the leaflabs crew.  Hopefully this saves someone who is having problems with a high density device using the additional interrupts from descending into the madness that is ld :). &#60;/p&#62;
&#60;p&#62;The bug report is here: &#60;a href=&#34;http://code.google.com/p/leaflabs/issues/detail?id=78&#34; rel=&#34;nofollow&#34;&#62;http://code.google.com/p/leaflabs/issues/detail?id=78&#60;/a&#62;
&#60;/p&#62;</description>
		</item>
		<item>
			<title>r1s3n on "libmaple - Interrupt vector problem"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1274#post-7634</link>
			<pubDate>Fri, 13 Jan 2012 22:55:00 +0000</pubDate>
			<dc:creator>r1s3n</dc:creator>
			<guid isPermaLink="false">7634@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Hi everyone, I'm not sure that this is a IDE problem since I'm using libmaple with make and friends, but it's definitely not hardware related, so I guess my problem belongs here. Before I get started, I'm totally digging all the power these ARM mcus provide and your boards make them incredibly attractive :).  Any plans on using the STM32 F4 chips in a future edition?  &#60;/p&#62;
&#60;p&#62;Just to lay the groundwork: I'm working on a 64 bit debian VM (6.0.3) with libmaple.  I've compiled a bunch of the test applications and they seem to work OK.  The USB is handled correctly, at least.  I've gotten quite a ways working with the board and I wanted to start messing with the interrupts from the timer.  Specifically, the input capture on timer8 ch 4 which, luckily, is on the RET6's button.  I have everything setup correctly and without interrupts enabled I can see that the timer value is captured into the proper register.  However, once I enable interrupts, the moment it tries to run the interrupt the board freezes for 2s or so then throbs :*( .  &#60;/p&#62;
&#60;p&#62;I've spent a little while and tracked this back to what I believe is the source of the problem.  I'm not sure why, but it appears that the linker scripts aren't setting up the interrupt table correctly.  The interrupts for timer8 or timer1 aren't all being set correctly when I build an application against libmaple.  I've just grabbed the latest from github and built the libmaple/examples/test-timers.cpp by copying it into the libmaple/ directory and running make.  It builds fine, but when I go and look at the dissassembly I see the same sort of thing I see when I build my code.  The interrupt table from the disassembly is below.  I've verified with a small program that it's exactly what is seen when the program is loaded to hardware, so there's definitely something funny up.  The first tip is that there's many non-word aligned addresses in the interrupt table.  I'm not an expert on ARM but shouldn't they all be word aligned?  Though, even if non-word aligned code is OK, the compiler seems to be generating all word aligned entries to functions.  I've also hand-verified some of the addresses in the table and they point into the middle of functions in the disassembly.  &#60;/p&#62;
&#60;p&#62;Now, there's a chance that I've gone and done something to cause my own pain here, but I just don't see how.  I looked over the linker scripts and there isn't a whole lot going on to generate the interrupt table (again, this is like the 2nd or 3rd time I've had to look at those, so I could be totally wrong).  Below is the interrupt table and a few of the addresses for the interrupts.&#60;/p&#62;
&#60;pre&#62;&#60;code&#62;build/maple_RET6.elf:     file format elf32-littlearm

Disassembly of section .text:

08005000 &#38;lt;__cs3_stm32_vector_table&#38;gt;:
 8005000:	00 00 01 20 49 99 00 08 21 72 00 08 25 72 00 08     ... I...!r..%r..
 8005010:	29 72 00 08 2d 72 00 08 31 72 00 08 45 99 00 08     )r..-r..1r..E...
 8005020:	45 99 00 08 45 99 00 08 45 99 00 08 4d 7c 00 08     E...E...E...M&#124;..
 8005030:	45 99 00 08 45 99 00 08 71 7c 00 08 d1 57 00 08     E...E...q&#124;...W..
 8005040:	45 99 00 08 45 99 00 08 45 99 00 08 45 99 00 08     E...E...E...E...
 8005050:	45 99 00 08 45 99 00 08 fd 52 00 08 f7 52 00 08     E...E....R...R..
 8005060:	f1 52 00 08 eb 52 00 08 e5 52 00 08 f9 51 00 08     .R...R...R...Q..
 8005070:	09 52 00 08 19 52 00 08 29 52 00 08 39 52 00 08     .R...R..)R..9R..
 8005080:	49 52 00 08 59 52 00 08 45 99 00 08 45 99 00 08     IR..YR..E...E...
 8005090:	7d 61 00 08 45 99 00 08 45 99 00 08 51 53 00 08     }a..E...E...QS..
 80050a0:	dd 58 00 08 fd 58 00 08 51 59 00 08 c5 59 00 08     .X...X..QY...Y..
 80050b0:	79 5a 00 08 6d 5a 00 08 61 5a 00 08 c5 56 00 08     yZ..mZ..aZ...V..
 80050c0:	49 55 00 08 b9 56 00 08 55 55 00 08 45 99 00 08     IU...V..UU..E...
 80050d0:	45 99 00 08 99 5d 00 08 a5 5d 00 08 b1 5d 00 08     E....]...]...]..
 80050e0:	49 53 00 08 45 99 00 08 45 99 00 08                 IS..E...E...

risen@vsqueezebox:~/maple/libmaple/build$ grep __irq_tim[1\&#124;8] maple_RET6.disas
080058d0 &#38;lt;__irq_tim8_brk&#38;gt;:
 80058d0:	4b01      	ldr	r3, [pc, #4]	; (80058d8 &#38;lt;__irq_tim8_brk+0x8&#38;gt;)
080058dc &#38;lt;__irq_tim1_brk&#38;gt;:
 80058dc:	4b01      	ldr	r3, [pc, #4]	; (80058e4 &#38;lt;__irq_tim1_brk+0x8&#38;gt;)
080058f0 &#38;lt;__irq_tim8_up&#38;gt;:
 80058f0:	4b01      	ldr	r3, [pc, #4]	; (80058f8 &#38;lt;__irq_tim8_up+0x8&#38;gt;)
080058fc &#38;lt;__irq_tim1_up&#38;gt;:
 80058fc:	4b01      	ldr	r3, [pc, #4]	; (8005904 &#38;lt;__irq_tim1_up+0x8&#38;gt;)
08005944 &#38;lt;__irq_tim8_trg_com&#38;gt;:
 8005944:	4b01      	ldr	r3, [pc, #4]	; (800594c &#38;lt;__irq_tim8_trg_com+0x8&#38;gt;)
08005950 &#38;lt;__irq_tim1_trg_com&#38;gt;:
 8005950:	4b01      	ldr	r3, [pc, #4]	; (8005958 &#38;lt;__irq_tim1_trg_com+0x8&#38;gt;)
080059b8 &#38;lt;__irq_tim8_cc&#38;gt;:
 80059b8:	4b01      	ldr	r3, [pc, #4]	; (80059c0 &#38;lt;__irq_tim8_cc+0x8&#38;gt;)
080059c4 &#38;lt;__irq_tim1_cc&#38;gt;:
 80059c4:	4b01      	ldr	r3, [pc, #4]	; (80059cc &#38;lt;__irq_tim1_cc+0x8&#38;gt;)&#60;/code&#62;&#60;/pre&#62;</description>
		</item>

	</channel>
</rss>
