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.

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.