Custom build not starting after reset

(6 posts) (2 voices)

Started 1 year ago by jonatan.olofsson
Latest reply from bobc

jonatan.olofsson
Member

Hello,

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.

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)

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..

Any suggestions? What symbols are needed to be in what addresses for the soft reset to enter the application?

Posted 1 year ago #
jonatan.olofsson
Member

Further investigation led me to a very weird observation; every second reset start the application when manually built..

When building with the makefiles, every reset starts the application properly..

This result is invariable, and so occurs every time.

Posted 1 year ago #
jonatan.olofsson
Member

For future reference; Linking with the object files instead of libmaple.a solved the issue.

Posted 1 year ago #
bobc
Member

Hi, I had exactly the same problem, and I think I have now got to the bottom of it.

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.

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!

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.

Therefore I think that changing the Flash build to put a zero word in the magic location will enable the bootloader to work correctly.

Posted 1 year ago #
bobc
Member

I notice that in one of the maple-bootloader forks this fix has been applied

https://github.com/chrismerck/maple-bootloader/commit/b6b45b6234dad20eda8e89a46ce7d5f825992195

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.

Posted 1 year ago #

bobc
Member

Here is my proposed workaround without changing the bootloader. Change common.inc as follows:

/*
     * .data
     */
    .data :
      {
        __data_start__ = .;
      	LONG(0)
        . = ALIGN(8);

        *(.got.plt) *(.got)
        *(.data .data.* .gnu.linkonce.d.*)

        . = ALIGN(8);
        __data_end__ = .;
      } > REGION_DATA AT> REGION_RODATA

LeafLabs Garden

Custom build not starting after reset

Reply