> On Nov 30, 2017, at 1:51 AM, K Dmitry <[email protected]> wrote: > > 29.11.2017, 21:34, "marko kiiskila" <[email protected]>: >> I don’t think the system is even booting properly. >> If you run it under debugger, can you verify that you’re not reaching main()? > > Looks like it crashes before reaching main: > (gdb) load > Loading section .text, size 0x119a8 lma 0x8020 > Loading section .ARM.exidx, size 0x18 lma 0x199c8 > Loading section .data, size 0x25c lma 0x199e0 > Start address 0x80e0, load size 72732 > Transfer rate: 11837 KB/sec, 10390 bytes/write. > (gdb) bt > #0 Reset_Handler () at > repos/apache-mynewt-core/hw/bsp/nrf51dk/src/arch/cortex_m0/gcc_startup_nrf51.s:140 > (gdb) b main > Breakpoint 1 at 0x84dc: file > repos/apache-mynewt-core/apps/lora_app_shell/src/main.c, line 128. > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0xfffffffe in ?? () > (gdb) bt > #0 0xfffffffe in ?? () > #1 0x0000edea in console_out (c=48) at > repos/apache-mynewt-core/sys/console/full/src/uart_console.c:142 > #2 0x0000e8f0 in console_write (str=<optimized out>, cnt=cnt@entry=1) at > repos/apache-mynewt-core/sys/console/full/src/console.c:99 > #3 0x000140b8 in stdout_write (fp=<optimized out>, bp=<optimized out>, n=1) > at repos/apache-mynewt-core/libc/baselibc/src/mynewt.c:32 > #4 0x000142b8 in fwrite (stream=0x140b9 <stdout_write+12>, nmemb=1, size=1, > buf=0x20007dff) > at repos/apache-mynewt-core/libc/baselibc/include/stdio.h:59 > #5 fputc (f=0x140b9 <stdout_write+12>, c=48) at > repos/apache-mynewt-core/libc/baselibc/include/stdio.h:75 > #6 putf (putp=putp@entry=0x20000318 <_stdin>, c=c@entry=48 '0') at > repos/apache-mynewt-core/libc/baselibc/src/tinyprintf.c:137 > #7 0x000143a8 in putchw (putp=putp@entry=0x20000318 <_stdin>, > p=p@entry=0x20007e48) > at repos/apache-mynewt-core/libc/baselibc/src/tinyprintf.c:181 > #8 0x000145ba in tfp_format (putp=0x20000318 <_stdin>, fmt=0x18bc5 " ", > fmt@entry=0x1 "\200", va=...) > at repos/apache-mynewt-core/libc/baselibc/src/tinyprintf.c:302 > #9 0x00014714 in vfprintf (va=..., fmt=0x1 "\200", f=<optimized out>) at > repos/apache-mynewt-core/libc/baselibc/src/tinyprintf.c:355 > #10 printf (fmt=0x18bc0 "%06lu ") at > repos/apache-mynewt-core/libc/baselibc/src/tinyprintf.c:371 > #11 0x0000ec58 in console_printf (fmt=0x180e0 "Assert @ 0x%x\n") at > repos/apache-mynewt-core/sys/console/full/src/console_fmt.c:50 > #12 0x00009054 in __assert_func (file=file@entry=0x18204 > "repos/apache-mynewt-core/kernel/os/src/os.c", line=line@entry=186, > func=func@entry=0x0, e=e@entry=0x0) at > repos/apache-mynewt-core/kernel/os/src/arch/cortex_m0/os_fault.c:119 > #13 0x00009258 in os_init (main_fn=0x84dd <main>) at > repos/apache-mynewt-core/kernel/os/src/os.c:186 > #14 0x000082ec in _start () at > repos/apache-mynewt-core/libc/baselibc/src/start.c:37 > #15 0x00008122 in Reset_Handler () at > repos/apache-mynewt-core/hw/bsp/nrf51dk/src/arch/cortex_m0/gcc_startup_nrf51.s:189 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) >
This is a bit perplexing, especially as you’re able to run slinky target with this with no trouble. What might be useful is to figure out which interrupt it is processing. You could add a breakpoint to os_init(), and do ‘info reg’ or ‘info reg all’, and then inspect the contents of xPSR. Another thing which might give some clues would be to check if you’re re-entering Reset_Handler() or _start() without going through proper MCU reset cycle. To check that, I would add breakpoints at Reset_Handler, _start, os_arch_init and even main. And then do ‘mon reset’ from gdb, and make sure that all the routines above are hit only once, and in the order they appear above. One thing of interest with nrf51 is that there’s no way for us to detect if debugger is attached or not, so we cannot drop into debugger automatically when we detect a fault. So when debugging, I add breakpoints at __assert_func and at os_default_irq_asm (maybe we should do that automatically in the gdb startup script for nrf51 bsps?) to catch the fault as soon as possible. Sorry for not being more helpful right away; it’s been a while since I messed around with the startup code, so I’m a bit rusty, and the advice might or might not be useful. > > >> Lastly: did you build and load the bootloader on this device? I see that you >> have a bootloader target but I did not see in the list of commands if you >> built and loaded it. > > Sure. I loaded it while was playing with slinky example. And loading slinky > instead of lora app works fine. >
