You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Marcos Scheeren <ma...@infinitoom.com> on 2017/02/14 07:00:34 UTC
Issues with bleprph and blecent on nRF51822xxaa
Hi,
Last month I was having some issues loading the compiled code to the board
without OpenOCD or JLink, just using GDB extended-remote mode, that seems
to be solved now - Thanks Marko and Chris for the help!
So, I edited the linker script to flash the board at address 0x0 (removed
the header offset) and then building the targets and loading the outputted
.elf file onto the board via GDB "load" command.
And it worked fine for the blinky app and the bletest app, I can even scan
the bletest when set as advertiser on my android phone so the ble stack
seems to be working fine too. The console over UART also works.
But couldn't get blecent or bleprph to work. Both fail.
(Still can't use GDB "restore" on extended-remote, gives me "Writing to
flash memory forbidden in this context" =/ )
Here are my target settings:
newt target show
targets/my_blinky_sim
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
targets/nrf51_blecent
app=@apache-mynewt-core/apps/blecent
bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
build_profile=optimized
targets/nrf51_bleprph
app=@apache-mynewt-core/apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
build_profile=optimized
targets/nrf51_bletest
app=@apache-mynewt-core/apps/bletest
bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
build_profile=optimized
targets/nrf51_blinky
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
build_profile=optimized
(Build runs fine! no ram or flash errors.)
On the gdb console I got this:
"Program received signal SIGTRAP, Trace/breakpoint trap.
Reset_Handler ()
at
repos/apache-mynewt-core/hw/bsp/nrf51dk-16kbram/src/arch/cortex_m0/gcc_startup_nrf51.s:140
140 MOVS R1, #NRF_POWER_RAMONx_RAMxON_ONMODE_Msk"
and over UART I got:
"0:Assert @ 0x10eeb
0:Unhandled interrupt (2), exception sp 0x20000b68"
If I check the assertion error at 0x10eeb shown on the UART console above
it reads "<ble_hci_ram_pkg_init+42>: 0x003a0cbd" on GDB.
"$newt version" outputs "Apache Newt (incubating) version: 1.0.0.b2"
If I try to run it step by step, somewhere in the execution it shows
"OS_INVALID_PARM" and "OS_MEM_NOT_ALIGNED"
Also, tried to run on previous tags (changed both newt tool and mynewt
core, new mynewt project dir) like mynewt_1_0_0_b1_tag, same "Unhandled
interrupt (2)" error for both bleprph and blecent.
Any thoughts why bletest works and other apps doesn't? Any other useful
information I could provide? Could it be related to unaligned memory blocks
due to the modified linker script?
Thanks!!
Marcos S.
Re: Issues with bleprph and blecent on nRF51822xxaa
Posted by Marcos Scheeren <ma...@infinitoom.com>.
On Fri, Feb 17, 2017 at 3:38 AM, will sanfilippo <wi...@runtime.io> wrote:
> Hello there Marcos:
>
> Indeed, some of the sample apps probably wont run in 16KB RAM. If a malloc fails it should be pretty easy to debug as I would suspect most mallocs in the code assert() if they cant get the memory.
>
> Is there a specific app your want to run?
>
>
Hi!
Good hint! I'm going to look into the assertions throughout the code
to see if it can help debugging mallocs.
I was looking for running something that would support BLE peripheral,
it seems that now I got it working..
But yes, 16kb RAM implies in a few limitations (compared to something
like a M4F nrf52)
Thank you,
Marcos
Re: Issues with bleprph and blecent on nRF51822xxaa
Posted by will sanfilippo <wi...@runtime.io>.
Hello there Marcos:
Indeed, some of the sample apps probably wont run in 16KB RAM. If a malloc fails it should be pretty easy to debug as I would suspect most mallocs in the code assert() if they cant get the memory.
Is there a specific app your want to run?
> On Feb 16, 2017, at 8:19 PM, Marcos Scheeren <ma...@infinitoom.com> wrote:
>
> Hi, Marko.
>
> On Tue, Feb 14, 2017 at 2:33 PM, marko kiiskila <ma...@runtime.io> 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.
Re: Issues with bleprph and blecent on nRF51822xxaa
Posted by Marcos Scheeren <ma...@infinitoom.com>.
Hi there!
On Fri, Feb 17, 2017 at 5:45 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>
> 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.
>
It seems like I could use all the gdb commands accordingly, even "restore" is
accepted now but when I tried running the app, it behaves like nothing
was written...
I may be still missing something (or maybe it doesn't work at all with my bmp).
But it's ok, the process below seems to work better overall.
>
> 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.
>
So, that worked very well, now I can load the bootloader at 0x0 using the .elf
file, just like the newt j-link scripts do, and then "load
<file>.srec" in gdb to the proper
bsp flash areas.
With that and setting some syscfg.yml - with some feedback I got from Jacob back
in January - I got bleprph example to work which is the one I was looking for.
Now that it worked, it's up to mess around with the app code itself. =)
Since the mcu it's the same as nrf51dk-16kbram (the nrf51822xxaa), I just cloned
everything from nrf51dk-16kbram bsp and made two minor tweaks like changing
UART TX/RX pins and LED_BLINK_PIN.
>
> Ah, my bad! I remembered the symbol name for end-of-heap incorrect.
> Instead, say:
>
> p/d sbrkLimit - brk
>
>
There you go, for some examples I tried with a few syscfg as follows:
the outputs of "p/d sbrkLimit - brk" are:
blinky: 6996 (runs ok)
blehci: 2332 (runs ok)
bletest: 452 (runs ok)
bleprph: 332 (fail)
bleprph with syscfg: 3212 (runs ok)
blecent: 748 (fail)
blecent with syscfg: 72 (fail)
syscfg.vals:
BLE_LL_CFG_FEAT_LE_ENCRYPTION: 0
BLE_LL_NUM_SCAN_DUP_ADVS: 0
BLE_SM_LEGACY: 0
CONFIG_NEWTMGR: 0
LOG_CLI: 0
LOG_LEVEL: 255
LOG_NEWTMGR: 0
MSYS_1_BLOCK_COUNT: 8
MSYS_1_BLOCK_SIZE: 76
SHELL_TASK: 1
STATS_NAMES: 0
STATS_NEWTMGR: 0
>
> I’m pretty certain not all of those have been tried. Others on the list might have
> more data on this.
>
Thanks a lot for the help for now! I'll let you know for any progress
here that may be
useful for others on the community.
Hopefully I can get some debugger scripts to support the black magic
probe.. still
tweaking and working on these.
Thanks,
Marcos
Re: Issues with bleprph and blecent on nRF51822xxaa
Posted by marko kiiskila <ma...@runtime.io>.
> On Feb 16, 2017, at 8:19 PM, Marcos Scheeren <ma...@infinitoom.com> wrote:
>
> Hi, Marko.
>
> On Tue, Feb 14, 2017 at 2:33 PM, marko kiiskila <ma...@runtime.io> 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.
Re: Issues with bleprph and blecent on nRF51822xxaa
Posted by Marcos Scheeren <ma...@infinitoom.com>.
Hi, Marko.
On Tue, Feb 14, 2017 at 2:33 PM, marko kiiskila <ma...@runtime.io> 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.
Re: Issues with bleprph and blecent on nRF51822xxaa
Posted by marko kiiskila <ma...@runtime.io>.
Hi,
> On Feb 13, 2017, at 11:00 PM, Marcos Scheeren <ma...@infinitoom.com> wrote:
>
> Hi,
>
> Last month I was having some issues loading the compiled code to the board
> without OpenOCD or JLink, just using GDB extended-remote mode, that seems
> to be solved now - Thanks Marko and Chris for the help!
>
> So, I edited the linker script to flash the board at address 0x0 (removed
> the header offset) and then building the targets and loading the outputted
> .elf file onto the board via GDB "load" command.
Ok. That should indeed work.
> And it worked fine for the blinky app and the bletest app, I can even scan
> the bletest when set as advertiser on my android phone so the ble stack
> seems to be working fine too. The console over UART also works.
> But couldn't get blecent or bleprph to work. Both fail.
> (Still can't use GDB "restore" on extended-remote, gives me "Writing to
> flash memory forbidden in this context" =/ )
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.
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.
>
> Here are my target settings:
> newt target show
> targets/my_blinky_sim
> app=apps/blinky
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> targets/nrf51_blecent
> app=@apache-mynewt-core/apps/blecent
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
> build_profile=optimized
> targets/nrf51_bleprph
> app=@apache-mynewt-core/apps/bleprph
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
> build_profile=optimized
> targets/nrf51_bletest
> app=@apache-mynewt-core/apps/bletest
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
> build_profile=optimized
> targets/nrf51_blinky
> app=apps/blinky
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram
> build_profile=optimized
>
> (Build runs fine! no ram or flash errors.)
>
>
> On the gdb console I got this:
> "Program received signal SIGTRAP, Trace/breakpoint trap.
> Reset_Handler ()
> at
> repos/apache-mynewt-core/hw/bsp/nrf51dk-16kbram/src/arch/cortex_m0/gcc_startup_nrf51.s:140
> 140 MOVS R1, #NRF_POWER_RAMONx_RAMxON_ONMODE_Msk"
>
>
> and over UART I got:
> "0:Assert @ 0x10eeb
> 0:Unhandled interrupt (2), exception sp 0x20000b68”
>
>
> If I check the assertion error at 0x10eeb shown on the UART console above
> it reads "<ble_hci_ram_pkg_init+42>: 0x003a0cbd" on GDB.
My guess the system is out of heap. Check while in gdb:
p/d sbrkBase-brk
Hopefully there are things you can prune out.
>
> "$newt version" outputs "Apache Newt (incubating) version: 1.0.0.b2"
>
>
> If I try to run it step by step, somewhere in the execution it shows
> "OS_INVALID_PARM" and “OS_MEM_NOT_ALIGNED"
Line number data gets a bit muddy when compiling with optimizer on.
So you’re probably not actually returning with those values.
> Also, tried to run on previous tags (changed both newt tool and mynewt
> core, new mynewt project dir) like mynewt_1_0_0_b1_tag, same "Unhandled
> interrupt (2)" error for both bleprph and blecent.
>
>
> Any thoughts why bletest works and other apps doesn't? Any other useful
> information I could provide? Could it be related to unaligned memory blocks
> due to the modified linker script?
Highly unlikely that the linker scripts would cause this.
I suspect it’s the RAM usage.
Let me know how it goes,
M