Hi Jan, Maybe start with just blinky application to see if problem is build related. With blinky you could safely share elf file so I could check if everything looks ok.
Maybe you created image from your build with newt tool that added image header that you don't want since you don't have mcuboot as bootloader. Try loading elf file with debugger directly without using newt load. br Jerzy pt., 24 sty 2025 o 11:50 Jan Clement <jan.clem...@cm-electronics.de> napisał(a): > Hey Jerzy, > > thanks for your help! > > I already changed the adress of slot 0 in the bsp but this didn't > resolve the problem. I tried using my old linker script, and now the > problem counter is at least in the right range. Below is my *.map file: > > > > > There are no discarded input sections > > > > Memory Configuration > > > > Name Origin Length Attributes > > FLASH 0x08000000 0x000f8000 xr > > ITCM 0x00000000 0x00004000 xr > > DTCM 0x20000000 0x00010000 xrw > > DATA_NO_CACHE 0x20010000 0x00000200 xrw > > RAM 0x20010200 0x0003fe00 xrw > > SDRAM 0xc0000000 0x00f80800 xrw > > *default* 0x00000000 0xffffffff > > > > Linker script and memory map > > > > START GROUP > > .... > > END GROUP > > LOAD > C:/msys64/mingw64/bin/../lib/gcc/arm-none-eabi/14.2.1/thumb/v7e-m/nofp\libgcc.a > > START GROUP > > LOAD > C:/msys64/mingw64/bin/../lib/gcc/arm-none-eabi/14.2.1/thumb/v7e-m/nofp\libgcc.a > > ... > > END GROUP > > 0x00000000 _imghdr_size = 0x0 > > > > .glue_7 0x08000000 0x0 > > .glue_7 0x08000000 0x0 linker stubs > > > > .glue_7t 0x08000000 0x0 > > .glue_7t 0x08000000 0x0 linker stubs > > > > .vfp11_veneer 0x08000000 0x0 > > .vfp11_veneer 0x08000000 0x0 linker stubs > > > > .v4_bx 0x08000000 0x0 > > .v4_bx 0x08000000 0x0 linker stubs > > > > .SDRAM 0xc0000000 0x0 > > 0xc0000000 . = ALIGN (0x4) > > *(.SDRAM) > > > > .DATA_NO_CACHE 0x20010000 0x0 > > 0x20010000 . = ALIGN (0x4) > > 0x20010000 _s_ram_nocache = . > > *(.ram_nocache) > > 0x20010000 . = ALIGN (0x4) > > 0x20010000 _e_ram_nocache = . > > > OUTPUT(C:/Users/admin/git/proj/bin/targets/demo/app/apps/iptest/iptest.elf > elf32-littlearm) > > LOAD linker stubs > > For testing I changed the flash adress to 0x08000000, in my old setup > this worked and let me use the system without bootloader. > > Do you have any idea what could be wrong? As always I'm very thankful > for tips and hints, I really have to get this going fast.. > > Regards > Jan > > Am 22.01.2025 um 17:52 schrieb Jerzy Kasenberg: > > Hi Jan, > > > > I checked some more. > > BSP you mentioned has SLOT0 located at 0x08020000, you mentioned > 0x08010000 > > as your starting point so you may check this. > > > > I also checked that if you specify in your target syscfg.yml (or in > > application or bsp) > > INCLUDE_IMAGE_HEADER: 0 > > it should have same effect as _imghdr_size = 0x0; > > basically it means that image header (32 bytes for MCUBOOT) is not to be > > reserved. It can be verified in .map file look for something like that: > > > > .image_header > > *(.image_header) > > > > .interrupts 0x08040000 0x1f8 > > 0x08040000 . = ALIGN (0x4) > > 0x08040000 __isr_vector = . > > 0x08040000 __isr_vector_start = . > > > > This was taken from STM32F767 which has slot0 located at 0x8040000 > > Following fragment is from build that has INCLUDE_IMAGE_HEADER: 1 > > > > .image_header 0x08040000 0x20 > > *(.image_header) > > .image_header 0x08040000 0x20 > > > H:\msys64\home\Jerzy\work\blinky\bin\targets\nucleo-f767zi-iptest\app\@apache-mynewt-core\mgmt\image_header\@apache-mynewt-core_mgmt_image_header.a(image_header.o) > > 0x08040000 image_header > > > > .interrupts 0x08040020 0x1f8 > > 0x08040020 . = ALIGN (0x4) > > 0x08040020 __isr_vector = . > > 0x08040020 __isr_vector_start = . > > > > So you can see that interrupt vectors are moved 32 bytes allowing for > newt > > to insert image header. > > > > In any case if your custom bootloader jumps to 0x8010000 it should not > work > > before as well > > _imghdr_size = 0 means that there is not space for image header but > > interrupt vectors starting from initial SP are at the very beginning of > you > > build. > > Unless you have something special at 0x8010000 your code should jump to > > address store in 0x08010004 > > > > If your share some fragment of map file I can help you some more. > > > > br > > Jerzy > > > > śr., 22 sty 2025 o 16:36 Jerzy Kasenberg <jerzy.kasenb...@codecoup.pl> > > napisał(a): > > > >> Hi Jan, > >> > >> Easiest way for you to proceed is to get old linker scripts that worked > >> for you before > >> Then instead of having bsp.yml file with line > >> > >> bsp.linkerscript: autogenerated > >> > >> set bsp.linkerscript to what it was before > >> > >> I'll check your case to see how to manage it using autogenerated scripts > >> and let you know later > >> > >> br > >> Jerzy > >> > >> śr., 22 sty 2025 o 13:44 Jan Clement <jan.clem...@cm-electronics.de> > >> napisał(a): > >> > >>> Hello Devlist, > >>> > >>> during my process of upgrading apache mynewt from 1.9.0 to 1.13.0 I now > >>> face the problem, that the binaries I generate are not running on my > >>> system. > >>> > >>> As a starting point I used the iptest application and the > >>> stm32f7discovery bsp package. This worked with the old mynewt version. > I > >>> run my own bootloader implementation, after booting, it jumps to > >>> 0x08010000 and starts executing from there. For this to work in the old > >>> implementation I had to set > >>> > >>> > _imghdr_size = 0x0; /* size = 0 for direct flashing */ > >>> in the linker script. > >>> > >>> I can't find any corresponding setting in the new version. The only > >>> thing I found is: > >>> > >>> > INCLUDE_IMAGE_HEADER > >>> which I set to 0. > >>> > >>> For testing purposes I also tried to flash the image directly and use > it > >>> without the bootloader, this also didn't work. > >>> > >>> When I debug my application I get following output: > >>> > >>> > xPSR: 00000000 pc: 00000000 msp: 0x96f3b83c > >>> > >>> It seems that my program counter is not set correctly. > >>> > >>> Any help is greatly appreciated, thanks! > >>> > >>> Jan > >>> > >> > > > >
