<?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: Flashing bootloader over XBee</title>
		<link>http://forums.leaflabs.com/topic.php?id=48</link>
		<description>A place to share, learn, and grow...</description>
		<language>en-US</language>
		<pubDate>Fri, 22 Jan 2016 00:14:58 +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=48" rel="self" type="application/rss+xml" />

		<item>
			<title>bnewbold on "Flashing bootloader over XBee"</title>
			<link>http://forums.leaflabs.com/topic.php?id=48#post-273</link>
			<pubDate>Mon, 21 Jun 2010 16:46:03 +0000</pubDate>
			<dc:creator>bnewbold</dc:creator>
			<guid isPermaLink="false">273@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;I'm not super familiar with the XBee, but if it's got any extra programmable digital IO you could carefully wire it up to the Maple's reset and serial bootloader pins to enter that mode remotely (this would save rewriting a USART bootloader). &#60;/p&#62;
&#60;p&#62;FWIW, we're thinking about scrapping the old bootloader codebase and reimplementing it on top of libmaple. There wouldn't be any change in functionality, we just haven't cleaned up the bootloader code at all since we got it working and there's a lot of shared code between it and libmaple.&#60;/p&#62;
&#60;p&#62;Also, I recently wrote up a UNIX toolchain guide that might be useful, though perhaps too late for you: &#60;a href=&#34;http://leaflabs.com/docs/libmaple/unix-toolchain/&#34; rel=&#34;nofollow&#34;&#62;http://leaflabs.com/docs/libmaple/unix-toolchain/&#60;/a&#62;
&#60;/p&#62;</description>
		</item>
		<item>
			<title>coreyfro on "Flashing bootloader over XBee"</title>
			<link>http://forums.leaflabs.com/topic.php?id=48#post-234</link>
			<pubDate>Fri, 11 Jun 2010 12:19:58 +0000</pubDate>
			<dc:creator>coreyfro</dc:creator>
			<guid isPermaLink="false">234@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;So far, I've just updated the bootloader with a copy built from git.  It's just me testing my build environment.&#60;/p&#62;
&#60;p&#62;Just for argument sake, I did use an FTDI to flash the Maple directly, and through the xbee sockets, and it operated flawlessly at 115200, so it is specifically an XBEE problem.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>poslathian on "Flashing bootloader over XBee"</title>
			<link>http://forums.leaflabs.com/topic.php?id=48#post-224</link>
			<pubDate>Thu, 10 Jun 2010 10:00:33 +0000</pubDate>
			<dc:creator>poslathian</dc:creator>
			<guid isPermaLink="false">224@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;that would be excellent. Are you uploading code linked with libmaple or just raw binaries? I believe if you do a &#34;make jtag&#34; (as opposed to make ram, or make flash) in the libmaple directory, you can create regular sketch style programs that are targetted and being directly flashed via the serial bootloader or jtag.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>coreyfro on "Flashing bootloader over XBee"</title>
			<link>http://forums.leaflabs.com/topic.php?id=48#post-223</link>
			<pubDate>Thu, 10 Jun 2010 02:42:48 +0000</pubDate>
			<dc:creator>coreyfro</dc:creator>
			<guid isPermaLink="false">223@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;I have made a shield with an XBee socket that talks to the first serial UART (pins 7 and 8) and I have successfully flashed the Maple over this connection.&#60;/p&#62;
&#60;p&#62;I have been trying to make the connection more robust because it fails intermittently.  Right now I have my XBee modules running at 9600 baud, Even Parity, 12 802.15.4 retries, 4 byte packet length, and flashing fails about 50% of the time.  This is, doubtless, an XBee problem, but if there is any way to make stm32loader.py more resilient, let me know.&#60;/p&#62;
&#60;p&#62;I'm thinking about seeing if I can add a retry counter to stm32loader.py and see if rewriting-to/rereading-from an address after a timeout is a safe process.&#60;/p&#62;
&#60;p&#62;Once I get this working well, I hope to make a bootloader that can recieve updates over the hardware uarts.
&#60;/p&#62;</description>
		</item>

	</channel>
</rss>
