http://forums.leaflabs.com/topic.php?id=74384 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:04:56 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=74384#post-105596 Thu, 01 Jan 2015 08:29:29 +0000 bobc 105596@http://forums.leaflabs.com/ <p>Here is my proposed workaround without changing the bootloader. Change common.inc as follows:</p> <pre><code>/* * .data */ .data : { __data_start__ = .; LONG(0) . = ALIGN(8); *(.got.plt) *(.got) *(.data .data.* .gnu.linkonce.d.*) . = ALIGN(8); __data_end__ = .; } &gt; REGION_DATA AT&gt; REGION_RODATA</code></pre> <p>This ensures that the first word in RAM of Flash build is zero. </p> http://forums.leaflabs.com/topic.php?id=74384#post-105595 Wed, 31 Dec 2014 16:25:17 +0000 bobc 105595@http://forums.leaflabs.com/ <p>I notice that in one of the maple-bootloader forks this fix has been applied </p> <p><a href="https://github.com/chrismerck/maple-bootloader/commit/b6b45b6234dad20eda8e89a46ce7d5f825992195" rel="nofollow">https://github.com/chrismerck/maple-bootloader/commit/b6b45b6234dad20eda8e89a46ce7d5f825992195</a></p> <p>which just disables jump to RAM. I must admit RAM builds are not a feature I ever use on embedded targets, but I guess some people might want to use it. </p> http://forums.leaflabs.com/topic.php?id=74384#post-105594 Wed, 31 Dec 2014 16:15:48 +0000 bobc 105594@http://forums.leaflabs.com/ <p>Hi, I had exactly the same problem, and I think I have now got to the bottom of it.</p> <p>The Maple bootloader has a rather simple way of checking if a RAM download is present. At startup it checks a single location in RAM for a value that matches a RAM address. The assumption is that a RAM build will have the vector table at start of RAM, and the vector table is basically a list of address.</p> <p>Unfortunately, a Flash build can also have an address at the start of RAM, depending on how the linker allocates RAM. So the bootloader sees what it thinks is the vector table and jumps to RAM instead of Flash. OOPS!</p> <p>Modifying the bootloader to be more robust could be done, but in our case we want to be able to support existing bootloaders in the field, rather than have users update their bootloaders.</p> <p>Therefore I think that changing the Flash build to put a zero word in the magic location will enable the bootloader to work correctly. </p> http://forums.leaflabs.com/topic.php?id=74384#post-105566 Tue, 28 Oct 2014 14:10:32 +0000 jonatan.olofsson 105566@http://forums.leaflabs.com/ <p>For future reference; Linking with the object files instead of libmaple.a solved the issue. </p> http://forums.leaflabs.com/topic.php?id=74384#post-105563 Sun, 26 Oct 2014 04:56:37 +0000 jonatan.olofsson 105563@http://forums.leaflabs.com/ <p>Further investigation led me to a very weird observation; <em>every second</em> reset start the application when manually built..</p> <p>When building with the makefiles, every reset starts the application properly..</p> <p>This result is invariable, and so occurs every time. </p> http://forums.leaflabs.com/topic.php?id=74384#post-105562 Sat, 25 Oct 2014 19:30:44 +0000 jonatan.olofsson 105562@http://forums.leaflabs.com/ <p>Hello,</p> <p>I realize I am on unsupported territory by replacing the make build files with another buildsystem for libmaple, but it is indeed very rewarding to learn how to cross-compile the binaries from scratch.</p> <p>I have everything seemingly working except for one single issue: the application does not start after a reset, but requires a power cycle to start. (I posted about this earlier in "Anyone using libmaple.a?", but I then thought it would be more appropriate to start a new thread instead of hijacking bobc's)</p> <p>I've been poking around, comparing compile/link flags, checking with nm and reading ld-files to see where stuff are put. I am not too familiar with ld-files however, so I am not quite sure what to look for..</p> <p>Any suggestions? What symbols are needed to be in what addresses for the soft reset to enter the application? </p>