You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by marko kiiskila <ma...@runtime.io> on 2017/12/01 00:02:48 UTC
Re: Cannot build lora_app_shell
> On Nov 30, 2017, at 1:51 AM, K Dmitry <di...@yandex.ru> wrote:
>
> 29.11.2017, 21:34, "marko kiiskila" <ma...@runtime.io>:
>> 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.
>
Re: Cannot build lora_app_shell
Posted by will sanfilippo <wi...@runtime.io>.
I should have explained this in a bit more detail before. Sorry about that.
The code is crashing on the nrf51 because it is attempting to initialize too many gpio irqs. The issue with the code is that it can support both FSK modes and lora modes. Two of those interrupts are not used for lora and you do not have to initialize them. A quick check to see if this fixes the issue would be to comment out the init of irq4 and irq5 in SX1276IoIrqInit():
#if 0
rc = hal_gpio_irq_init(SX1276_DIO4, irqHandlers[4], NULL,
HAL_GPIO_TRIG_RISING, HAL_GPIO_PULL_NONE);
assert(rc == 0);
hal_gpio_irq_enable(SX1276_DIO4);
rc = hal_gpio_irq_init(SX1276_DIO5, irqHandlers[5], NULL,
HAL_GPIO_TRIG_RISING, HAL_GPIO_PULL_NONE);
assert(rc == 0);
hal_gpio_irq_enable(SX1276_DIO5);
#endif
That should get you past the assert you see and get you to the next one :-)
> On Dec 8, 2017, at 4:29 AM, K Dmitry <di...@yandex.ru> wrote:
>
>
>
> 01.12.2017, 20:34, "will sanfilippo" <wi...@runtime.io>:
>> Something does not quite make sense I have to say. Where it was crashing was in a very odd place; I can’t imagine different pins doing anything.
>>
> I've tried to trace it again on nrf51 and here is what I got.
>
> App gets to main() and crashes on sysinit(); call. Here is crash report:
>
> 16848468 Assert @ 0x10fcf
> 16848468 Unhandled interrupt (2), exception sp 0x20001488
> 16848468 r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
> 16848468 r4:0x00010fcf r5:0x0001968c r6:0xffffffff r7:0x0000a6e9
> 16848468 r8:0xffffffff r9:0xffffffff r10:0xffffffff r11:0xffffffff
> 16848468 r12:0xfffff7fe lr:0x0000904f pc:0x000081cc psr:0x81000200
> 16848468 ICSR:0x0041a002
>
> I've traced it to assert() after DIO4 irq init in SX1276IoIrqInit in sx1276-board.c
>
> Backtrace:
>
> #0 __assert_func (file=file@entry=0x196e8 "repos/apache-mynewt-core/hw/drivers/lora/sx1276/src/sx1276-board.c", line=line@entry=107,
> func=func@entry=0x0, e=e@entry=0x0) at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m0/os_fault.c:118
> #1 0x00010fce in SX1276IoIrqInit (irqHandlers=irqHandlers@entry=0x20000374 <DioIrq>)
> at repos/apache-mynewt-core/hw/drivers/lora/sx1276/src/sx1276-board.c:107
> #2 0x00011a06 in SX1276Init (events=<optimized out>) at repos/apache-mynewt-core/hw/drivers/lora/sx1276/src/sx1276.c:300
> #3 0x0000c6ec in LoRaMacInitialization (primitives=primitives@entry=0x20003c68 <g_lora_primitives>,
> callbacks=callbacks@entry=0x200014f8 <os_main_stack+4060>) at repos/apache-mynewt-core/net/lora/node/src/mac/LoRaMac.c:3518
> #4 0x0000b2d4 in lora_node_init () at repos/apache-mynewt-core/net/lora/node/src/lora_node.c:680
> #5 0x00010c12 in sysinit_app () at bin/targets/nrf51lora_app/generated/src/nrf51lora_app-sysinit-app.c:43
> #6 0x000084e6 in main () at repos/apache-mynewt-core/apps/lora_app_shell/src/main.c:133
>
Re: Cannot build lora_app_shell
Posted by K Dmitry <di...@yandex.ru>.
01.12.2017, 20:34, "will sanfilippo" <wi...@runtime.io>:
> Something does not quite make sense I have to say. Where it was crashing was in a very odd place; I can’t imagine different pins doing anything.
>
I've tried to trace it again on nrf51 and here is what I got.
App gets to main() and crashes on sysinit(); call. Here is crash report:
16848468 Assert @ 0x10fcf
16848468 Unhandled interrupt (2), exception sp 0x20001488
16848468 r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
16848468 r4:0x00010fcf r5:0x0001968c r6:0xffffffff r7:0x0000a6e9
16848468 r8:0xffffffff r9:0xffffffff r10:0xffffffff r11:0xffffffff
16848468 r12:0xfffff7fe lr:0x0000904f pc:0x000081cc psr:0x81000200
16848468 ICSR:0x0041a002
I've traced it to assert() after DIO4 irq init in SX1276IoIrqInit in sx1276-board.c
Backtrace:
#0 __assert_func (file=file@entry=0x196e8 "repos/apache-mynewt-core/hw/drivers/lora/sx1276/src/sx1276-board.c", line=line@entry=107,
func=func@entry=0x0, e=e@entry=0x0) at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m0/os_fault.c:118
#1 0x00010fce in SX1276IoIrqInit (irqHandlers=irqHandlers@entry=0x20000374 <DioIrq>)
at repos/apache-mynewt-core/hw/drivers/lora/sx1276/src/sx1276-board.c:107
#2 0x00011a06 in SX1276Init (events=<optimized out>) at repos/apache-mynewt-core/hw/drivers/lora/sx1276/src/sx1276.c:300
#3 0x0000c6ec in LoRaMacInitialization (primitives=primitives@entry=0x20003c68 <g_lora_primitives>,
callbacks=callbacks@entry=0x200014f8 <os_main_stack+4060>) at repos/apache-mynewt-core/net/lora/node/src/mac/LoRaMac.c:3518
#4 0x0000b2d4 in lora_node_init () at repos/apache-mynewt-core/net/lora/node/src/lora_node.c:680
#5 0x00010c12 in sysinit_app () at bin/targets/nrf51lora_app/generated/src/nrf51lora_app-sysinit-app.c:43
#6 0x000084e6 in main () at repos/apache-mynewt-core/apps/lora_app_shell/src/main.c:133
Re: Cannot build lora_app_shell
Posted by will sanfilippo <wi...@runtime.io>.
Something does not quite make sense I have to say. Where it was crashing was in a very odd place; I can’t imagine different pins doing anything.
I also have to apologize for not being a bit more helpful in regards to getting the code running on the nrf51. It is quite possible to do so. The lora driver code attempts to instantiate some GPIO interrupts that are actually not currently used. It would be easy enough to modify the code so those interrupts are not used and thus you could run it on a nrf51. Note that the lora driver code was ported from reference code from Semtech so it might be doing some things that are not needed.
Anyway, glad things work.
> On Dec 1, 2017, at 2:15 AM, K Dmitry <di...@yandex.ru> wrote:
>
>
>
> 01.12.2017, 13:11, "Fabio Utzig" <ut...@apache.org>:
>
>> Ah, sorry I might have missed something, but you wrote "I've bought
>> nrf52dk and build lora_app_shell for this target - still crashes." and
>> "lora app still crashes" at the end. Then it is working now and it was
>> just a matter of pin definitions?
>
> Well, it looks this way to me. I've tried nrf52dk yesterday and app was crashing. Today I've changed pins and syscfg according to example by will sanfilippo and app works.
Re: Cannot build lora_app_shell
Posted by K Dmitry <di...@yandex.ru>.
01.12.2017, 13:11, "Fabio Utzig" <ut...@apache.org>:
> Ah, sorry I might have missed something, but you wrote "I've bought
> nrf52dk and build lora_app_shell for this target - still crashes." and
> "lora app still crashes" at the end. Then it is working now and it was
> just a matter of pin definitions?
Well, it looks this way to me. I've tried nrf52dk yesterday and app was crashing. Today I've changed pins and syscfg according to example by will sanfilippo and app works.
Re: Cannot build lora_app_shell
Posted by Fabio Utzig <ut...@apache.org>.
On Fri, Dec 1, 2017, at 08:02 AM, K Dmitry wrote:
>
>
> 01.12.2017, 12:50, "Fabio Utzig" <ut...@apache.org>:
> > Do you mind attaching the output of "newt target config show
> > <your-target>"? I want to try reproducing the bug here.
>
> Guess there is no point in it any more. App finally runs on nrf52dk!
> I suppose it cannot run on nrf51, but was it incorrect pin definition
> that made it crash on nrf52?
> Should I investigate it?
Ah, sorry I might have missed something, but you wrote "I've bought
nrf52dk and build lora_app_shell for this target - still crashes." and
"lora app still crashes" at the end. Then it is working now and it was
just a matter of pin definitions?
Re: Cannot build lora_app_shell
Posted by K Dmitry <di...@yandex.ru>.
01.12.2017, 12:50, "Fabio Utzig" <ut...@apache.org>:
> Do you mind attaching the output of "newt target config show
> <your-target>"? I want to try reproducing the bug here.
Guess there is no point in it any more. App finally runs on nrf52dk!
I suppose it cannot run on nrf51, but was it incorrect pin definition that made it crash on nrf52?
Should I investigate it?
Re: Cannot build lora_app_shell
Posted by Fabio Utzig <ut...@apache.org>.
Do you mind attaching the output of "newt target config show
<your-target>"? I want to try reproducing the bug here.
On Fri, Dec 1, 2017, at 07:39 AM, K Dmitry wrote:
> Just a short update.
>
> I've bought nrf52dk and build lora_app_shell for this target - still
> crashes. Tried loraping app - crashes on both nrf devkits. Slinky works
> fine on both, tried btshell app on nrf52dk - it works. Updated SX1276 SPI
> pins according to bsp.c and updated syscfg with SX1276_SPI_CS_PIN and
> other mentioned earlier defines - lora app still crashes.
>
> Hope I'll have enough free time on weekend to debug deeper. I appreciate
> your help!
Re: Cannot build lora_app_shell
Posted by K Dmitry <di...@yandex.ru>.
Just a short update.
I've bought nrf52dk and build lora_app_shell for this target - still crashes. Tried loraping app - crashes on both nrf devkits. Slinky works fine on both, tried btshell app on nrf52dk - it works. Updated SX1276 SPI pins according to bsp.c and updated syscfg with SX1276_SPI_CS_PIN and other mentioned earlier defines - lora app still crashes.
Hope I'll have enough free time on weekend to debug deeper. I appreciate your help!