I think reset_handler() initializes the .data, .text, .bss and other sections in SRAM before calling runtime_init(), followed by calling main() and finally exit(). I assumed your bootloader was setting up the .data, .text and .bss sections in lieu of reset_handler() before calling runtime_init() and that the call to runtime_init() could be eli,inated because it has already been called. I guess what I'm proposing is copy pasting reset_handler() and the subroutines it calls with a version that doesn't call runtime_init(), only main() and exit().It isn't redundant - the new program is built entirely separately, has all of its variables in different places (just the sort of thing that runtime_init() initialises), and uses lots of SDK facilities that the bootloader does not.I think, since the bootloader is a regular SDK program, it causes runtime_init() and all the other things that happen before main() is called to happen. So it seems to me that, rather than the bootloader calling the main application's regular entry point, which would cause runtime_init() to be called again, that the bootloader could call the main application's main(), avoiding a second redundant call to runtime_init(), and in your case also undesirably resetting some GPIOs.
Code:
.type _reset_handler,%function.thumb_func_reset_handler: // Only core 0 should run the C runtime startup code; core 1 is normally // sleeping in the bootrom at this point but check to be sure ldr r0, =(SIO_BASE + SIO_CPUID_OFFSET) ldr r0, [r0] cmp r0, #0 bne hold_non_core0_in_bootrom // In a NO_FLASH binary, don't perform .data copy, since it's loaded // in-place by the SRAM load. Still need to clear .bss#if !PICO_NO_FLASH adr r4, data_cpy_table // assume there is at least one entry1: ldmia r4!, {r1-r3} cmp r1, #0 beq 2f bl data_cpy b 1b2:#endif // Zero out the BSS ldr r1, =__bss_start__ ldr r2, =__bss_end__ movs r0, #0 b bss_fill_testbss_fill_loop: stm r1!, {r0}bss_fill_test: cmp r1, r2 bne bss_fill_loopplatform_entry: // symbol for stack traces // Use 32-bit jumps, in case these symbols are moved out of branch range // (e.g. if main is in SRAM and crt0 in flash) ldr r1, =runtime_init blx r1 ldr r1, =main blx r1 ldr r1, =exit blx r1 // exit should not return. If it does, hang the core. // (fall thru into our hang _exit impl1: // separate label because _exit can be moved out of branch range bkpt #0 b 1bStatistics: Posted by alastairpatrick — Wed May 01, 2024 11:46 pm