> On Feb 16, 2017, at 8:19 PM, Marcos Scheeren <[email protected]> wrote: > > Hi, Marko. > > On Tue, Feb 14, 2017 at 2:33 PM, marko kiiskila <[email protected]> wrote: >> Hi, >> >> >> Quick peek to gdb sources tells me that the memory region is marked as >> flash, and comment says that only allow writes during ‘load’ phase (which, >> technically, I guess would be correct). Check the output of ‘info mem’, and >> see if you >> can change the properties of it. >> > > (gdb) info mem > Using memory regions provided by the target. > Num Enb Low Addr High Addr Attrs > 0 y 0x00000000 0x00040000 flash blocksize 0x400 nocache > 1 y 0x10001000 0x10001100 flash blocksize 0x100 nocache > 2 y 0x20000000 0x20004000 rw nocache
You could try removing the memory areas which are marked as flash, and then use restore. I.e. delete mem 0 delete mem 1 mem 0 0xffffffff rw nocache info mem restore <filename> binary <location> Depending on the gdb remote implementation, aka your black magic probe, this might or might not work. > >> Alternative would be to convert the binary blob into a ihex or srecord >> format. >> gdb can load these the same way as it can load elf. You can use objcopy >> to do that. Note that elf has location data, as do ihex and srecord. >> > > I tried "$ arm-none-eabi-objcopy bletest.elf.bin -O srec bletest.elf.bin.srec" > but it yields: arm-none-eabi-objcopy:bletest.elf.bin: File format not > recognized I don’t know what the flash map is like on your bsp.yml, but this is how you’d convert binary into srecord so I can’t give the correct start address. This is how you’d do it if you were to set the load address to 0x8000. arm-none-eabi-objcopy --adjust-vma=0x8000 -O srec -I binary blinky.img blinky.srec After this you should be able to do ‘load blinky.srec’ in gdb. > > When inputting the .elf file, it converts ok to both srec and ihex and GDB > accepts both just fine. > > >> >> My guess the system is out of heap. Check while in gdb: >> p/d sbrkBase-brk >> >> Hopefully there are things you can prune out. >> > > The output of p/d sbrkBase-brk in gdb: > blehci: -5392 > bletest: -1120 > bleprph: -192 > bleprph (BLE_LL_CFG_FEAT_LE_ENCRYPTION: 0 // BLE_SM_LEGACY: 0): -1072 > blecent: -1200 Ah, my bad! I remembered the symbol name for end-of-heap incorrect. Instead, say: p/d sbrkLimit - brk >> >> Highly unlikely that the linker scripts would cause this. >> I suspect it’s the RAM usage. > > Could it be that for some examples/apps 16KB MCUs aren't just enough? I’m pretty certain not all of those have been tried. Others on the list might have more data on this. >> >> Let me know how it goes, >> M >> >> > > Thank you. > Marcos.
