[ABANDONED] BootLoader jumps to reset-handler, executes it, but instead of jumping/blx-ing to "main()" EmbeddedStudio shows "unknown function"

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] BootLoader jumps to reset-handler, executes it, but instead of jumping/blx-ing to "main()" EmbeddedStudio shows "unknown function"

    Hello SEGGER-Forum:

    (this is related to forum-thread "Bootloader does not jump to application?" from earlier this month. Thank you for replying. Your answer
    proved helpful.)

    Scenario:
    Pre-condition: Embedded studio 3.50 or 4.10 or 4.12, 64bit, Windows10.
    gnu-assembler, gnu-compiler, gnu-linker. Simulation.
    Test-steps:
    (1) Application (current name: Hello_110818) being build by IDE, successfully tested in simulation as standalone project / solution.
    (2) Use SEGGEr-tool "bin2c" to create unsigned-char array from Hello_110818.
    (3) BootLoader (current name: Hello_BOOT) is supposed to "transfer-control" / "jump" to application. This application is being
    implemented as unsigned-char-array (see (2) above).
    (4) You start two independent-from-each-other SEGGER-EmbeddedStudio IDEs, one with Hello_110818 application, the other with Hello_BOOT bootloader (incl. Hello_110818 unsigned-char-array).
    (5) Your goal is to verify that F11-single-stepping in disassembler-windows shows the same results, both in (a) Hello_110818 application
    and when (b) BootLoader (Hello_BOOT) is supposed to jump to Application (Hello_110818).
    (6) While (F11-single-stepping works in either of both IDEs)
    { 1st F11-single-step in SEGGER IDE running Hello_110818;
    2nd F11-single-step in SEGGER IDE running Hello_110818 out of Hello_BOOT;
    }
    (7) Goal in (5) above is accomplished while F11-single-stepping through reset-handler (incl. zero-bss, init-of-heap, ctor-loop, setup-initial-
    call-frame,memory-set, tbss_start, thumb_crt0.s, ...). But note the different addresses in hexadecimal used between Hello_110818 and Hello_BOOT. Why are they different ?
    (8) Goal in (5) above is NOT accomplished when F11-single-stepping along the transfer-of-control from assembler-code (reset-handler) to
    c-code (main). Note that the addresses in hexadecimal used between Hello_110818 and Hello_BOOT are now the same. Why are they
    now the same ?
    Hello_BOOT SEGGER-IDE reports "unknown function" when supposed to jump to "main()". Hello_110818 SEGGER-IDE correctly jumps
    to "main()".

    I am attaching both projects. I am attaching some screen-shots taken during the lock-step F11-single-stepping in both Hello_110818 and
    Hello_BOOT before and during the jump to main() function.

    Above test-steps are reproducable with either gnu-{assembler,compiler}/SEGGER linker or gnu-{assembler,compiler}/GNU-linker.
    Above test-steps are not reproducible with clang{assembler, compiler}, "unknown function" are reported immediately when
    starting to exec the reset-handler of Hello_110818 out of Hello_BOOT.

    In Hello_BOOT, the setup of the processor, stacks, heaps, etc. is using functions derived from ARM's CMSIS-functions
    from github for M7.

    Visible results do not differ if SEGGER-tool "embed" is used instead of SEGGER-tool "bin2c" to create the unsigned-char-array, although the content of the unsigned-char-array differs between embed and bin2c.

    I am currently looking if the setup of the processor (CMSIS functions, see above) is impacting the execution, esp. the fact that the
    address-offsets being used are changing between reset-handler and main() function.

    Attachment in .zip format.
    Files
  • Hello,

    Thank you for your inquiry.
    To make sure we understand your setup here, you are trying to jump to an application after bootloader. Is that correct?
    Debugging the application standalone works as expected but when jumping from bootloader from same address does not. Correct?
    In your bootloader application you seem to be jumping to 0x300002ff. Why this specific point? When building the Hello application our selves we could not see any code at that address.

    seggfreddy wrote:

    But note the different addresses in hexadecimal used between Hello_110818 and Hello_BOOT. Why are they different ?
    Could you elaborate what you mean by that?


    seggfreddy wrote:

    Note that the addresses in hexadecimal used between Hello_110818 and Hello_BOOT are now the same. Why are they
    now the same ?
    What exactly is the same now?

    That Embedded Studio shows unknown function when jumping from bootloader to application is expected as there is no debug information in your c-array about the application so the debugger can't know what function he is in then.

    Best regards,

    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Happy New Year 2019.
    To answer your questions:
    (a-1) you are trying to jump to an application after bootloader. Is that correct?
    Answer: yes
    (a-2) Debugging the application standalone works as expected but when jumping from bootloader from same address
    does not. Correct?
    Answer: yes
    (a-3) In your bootloader application you seem to be jumping to 0x300002ff.
    Why this specific point? When building the Hello application our selves we could not see any code at
    that address.
    Answer: See file "hello_110818_array.c, which implements the "application" to be executed by the bootloader.
    Why 0x300002ff ?
    The boot-loader image contains char-array “hello_110118_array[]”,
    implemented in file hello_110818_array.c, created by embed-tool.
    Gcc __attribute__ statement is used to let “hello_110118_array[]” start at 0x30000000.
    Goal is to have boot-loader to “start” this application “hello_110118_array[]” at its reset-handler,
    which is implemented at 0x2ff offset in this char-array. (0x2ff is decimal 767, there are 16 hex-numbers
    per line in hello_110118_array[], i.e., editor-line# 52 shows 0x07, 0x48,
    editor-line#53 shows 0x85, 0x46.
    Disassembler window shows:
    4807 ldr r0,= 0x40100000
    4685 mov sp, r0
    See file Cortex_M_Startup.s In Hello_110818 directory, “.thumb_func reset_handler:”.
    I.e.,0x30000000 + 0x2ff == 0x300002ff.