Yes, there are problems loading app software to a nRF5x device with a Soft Device in the flash. I never analysed the reasons to such depth, I used one of possible easy workarounds: - convert app ELF binary to ihex, then 'flash write_image' cmd does not overwrite the Soft Device - use gdb, load command works for me
Of course any improvement of ELF handling would be appreciated. An additional splitting of a flash region content could cause issues with flash erase/write so the code around flash_bank.minimal_write_gap should stay functional and join the sections witch immediately follows before calling flash driver erase/write. Please also read comments in 7658: Revert "target/image: zero-initialize ELF segments up to p_memsz" | https://review.openocd.org/c/openocd/+/7658 --- **[tickets:#396] Shoud the ELF image code handle ELF sections rather than segments?** **Status:** new **Milestone:** 0.10.0 **Created:** Fri May 19, 2023 02:00 PM UTC by Aurélien Martin **Last Updated:** Fri May 19, 2023 02:04 PM UTC **Owner:** nobody Hello, Working with an nR52, I came to notice that flashing with OpenOCD a binary built by their SDK systematically erased part of the binary stack already present (SoftDevice). What happens is: * The SoftDevice lives at addresses 0x0 and following. It expects the program it loads (it behaves somewhat as an hypervisor) to be stored starting from 0x26000, and that's what the SDK does in its linker script for GCC: ~~~ MEMORY { FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000 RAM (rwx) : ORIGIN = 0x200018c8, LENGTH = 0xe738 } ~~~ * Though GCC heeds those bounds when allocating sections, the information seems lost on the resulting ELF program header, and the start of the corresponding memory segment gets aligned down to 0x20000: ~~~ 0x70000001 off 0x0000c850 vaddr 0x0002c850 paddr 0x0002c850 align 2**2 filesz 0x00000008 memsz 0x00000008 flags r-- LOAD off 0x00000000 vaddr 0x00020000 paddr 0x00020000 align 2**16 filesz 0x0000c858 memsz 0x0000c858 flags r-x LOAD off 0x000118c8 vaddr 0x200018c8 paddr 0x0002c858 align 2**16 filesz 0x00000148 memsz 0x000009e4 flags rw- private flags = 0x5000400: [Version5 EABI] [hard-float ABI] ~~~ I've played with other offsets, and the operation involved indeed seems to be an alignment down to the nearest 64 KB boundary. I got my hand on an old microcontroller framework of mine, with its own build system, which I had produces Openocd-flashable ELFs with a few years ago. It appears that those were working because I included the binary stack in the ELF, in its own memory segment. Then the "user flash" segment gets to keep its declared offset of 0x260000. Having data between the nearest 64K bound and the wanted offset does the trick. An empty segment doesn't. My thoughts on that, at that point: * This was observed with GCC and its ld. I don't know what other linkers do, nor what ELF specifies. This may be a GCC bug or not. It is surprising for GCC to lay out "data" where no memory is known to reside. * One way to work around this behavior would be to set arbitrary data in the gap, admitting such a gap exists, for each affected program. * I don't know why OpenOCD programs ELF segments rather than the sections. Maybe this is a matter of efficiency, reducing the number of write sequences. * If this was deemed acceptable, I would be willing to implement ELF handling by sections in OpenOCD, either unconditionally or submitted to some configuration item. Best regards --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
