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


> 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

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

>
> 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?

>
> Let me know how it goes,
> M
>
>

Thank you.
Marcos.

Reply via email to