Hi Alan.
Thanks for the response.
I forgot to add that I had tried to bisect things but I didn't get very far.
This could be down to something silly at my end but either I couldn't get a
successful build or I would hit the same situation as previously indicated.
I decided to poke a bit further and have some points to share in the hope
that they help:
I went back to the first commit where support for this board was added like
so:
$ cd nuttx
$ git whatchanged --pretty=oneline boards/arm/tiva/lm3s6965-ek/
configs/qemu-protected/defconfig | tail -n 2
702bc95cac16fe90cfaf8abb178b0822ba707521 tiva/lm3s6965-ek: Add a few
configs for qemu
$ git checkout -b test 702bc95cac16fe90cfaf8abb178b0822ba707521
$ ./tools/configure.sh lm3s6965-ek:qemu-protected
$ make -j(nproc)
.. which ended with:
===
AR (create): libboard.a lm_boot.o lm_leds.o lm_ethernet.o lm_ssi.o
lm_appinit.o lm_bringup.o
make[2]: Leaving directory 'nuttx_workspace/nuttx/boards/
arm/tiva/lm3s6965-ek/src'
LD: nuttx
arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you
mean --nostartfiles ?)
make[1]: *** [Makefile:172: nuttx] Error 1
make[1]: Leaving directory 'nuttx_workspace/nuttx/arch/arm/src'
make: *** [tools/Makefile.unix:412: nuttx] Error 2
===
I 'fixed' that by omitting the offending ld switches manually. I then got
the following:
$ qemu-system-arm \
-M lm3s6965evb \
-net nic,model=stellaris -net user,hostfwd=tcp:127.0.0.1:10023-
10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-10.0.2.15:21 \
-kernel nuttx -nographic
Timer with period zero, disabling
ABCDup_assert: Assertion failed at file:chip/common/tiva_userspace.c line:
87
irq_unexpected_isr: ERROR irq: 11
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 00000000 20001e58 0000000a 20000474 00000000 00000000
20002f8c 20000468
up_registerdump: R8: 00000000 00000000 00000000 00000000 00000008 20002f88
000060e7 000067a6
up_registerdump: xPSR: 61000200 PRIMASK: 00000000 CONTROL: 00000000
up_registerdump: EXC_RETURN: fffffff9
up_dumpstate: sp: 20002ec8
up_dumpstate: stack base: 000004d1
up_dumpstate: stack size: 000004d1
up_dumpstate: ERROR: Stack pointer is not within the allocated stack
up_stackdump: 00000000: 20002fe4 0000011d 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 00000020: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 00000040: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 00000060: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 00000080: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 000000a0: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 000000c0: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 000000e0: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 000004d1
up_stackdump: 00000100: 000004d1 000004d1 000004d1 000004d1 000004d1
000004d1 000004d1 f000b508
up_stackdump: 00000120: f000f8b1 2041fa15 fa0af000 4b172100 42934a17
2042d321 fa02f000 4a164b15
up_stackdump: 00000140: 428b4916 2043d31c f9faf000 fb12f000 f0002044
f000f9f5 2045f89d f9f0f000
up_stackdump: 00000160: f970f001 f0002046 200df9eb f9e8f000 f000200a
f001f9e5 f843f9a5 e7d81b04
I took care to ensure that my apps directory was reset to a date that
corresponded to the commit used for the nuttx directory.
Interestingly - and as indicated in my first post - a build with the latest
nuttx and apps dirs doesn't produce the above output. However, when I look
at my poor person's 'boot log' I see the same invocation of
irq_unexpected_isr.
My theory, therefore, is that lm3s6965-ek:qemu-protected has never worked
ever since support was committed ?
Also: I think the unexpected IRQ 11 (that's an SVC exception I think ?) has
been the problem since the beginning and continues to manifest even with
the latest nuttx.
I would appreciate any advice. I will try and explore a bit further myself
but I am very new to NuttX.
Cheers,
Robin
On Mon, 13 May 2024 at 22:35, Alan C. Assis <acas...@gmail.com> wrote:
> Hi Robin,
>
> Did you test previous release versions? It could be useful to know in which
> version the issue was introduced.
>
> After that we could use git bisect to pinpoint the commit that introduced
> this issues.
>
> Best Regards,
>
> Alan
>
> On Mon, May 13, 2024 at 5:41 PM Robin Randhawa <robin.randh...@gmail.com>
> wrote:
>
> > Hi.
> >
> > I find that:
> >
> > $ ./tools/configure.sh lm3s6965-ek:qemu-flat
> > $ make
> > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> tcp:127.0.0.1:10021-
> > 10.0.2.15:21 -kernel nuttx -nographic
> >
> > .. gets me to a nice NSH prompt with ping working.
> >
> > However, the following:
> >
> > $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> > $ make
> > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> tcp:127.0.0.1:10021-
> > 10.0.2.15:21 -kernel nuttx -nographic
> >
> > .. gets me:
> >
> > ====
> >
> > Timer with period zero, disabling
> > ABCEF
> >
> > ====
> >
> > .. with no other output.
> >
> > Adding qemu logging after disabling translation block chaining using:
> >
> > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> tcp:127.0.0.1:10021-
> > 10.0.2.15:21 -kernel nuttx -nographic -d nochain,in_asm -D /tmp/qemu.log
> >
> > .. and processing the log like so gives me (with apologies for the
> > verbosity):
> >
> > $ cat /tmp/qemu.log | grep ^IN | awk '!seen[$0]++' | nl
> > 1 IN: __start
> > 2 IN: tiva_clock_configure
> > 3 IN: tiva_clock_reconfigure
> > 4 IN: tiva_lowsetup
> > 5 IN: modifyreg32
> > 6 IN: tiva_configgpio
> > 7 IN: tiva_gpiobaseaddress
> > 8 IN: tiva_gpiofunc
> > 9 IN: tiva_gpiowrite
> > 10 IN: arm_lowputc
> > 11 IN: memset
> > 12 IN: memcpy
> > 13 IN: tiva_userspace
> > 14 IN: tiva_mpuinitialize
> > 15 IN: mpu_configure_region
> > 16 IN: mpu_allocregion
> > 17 IN: mpu_log2regionceil
> > 18 IN: mpu_subregion
> > 19 IN: mpu_control
> > 20 IN: tiva_boardinitialize
> > 21 IN: lm_ssidev_initialize
> > 22 IN: board_autoled_initialize
> > 23 IN: nx_start
> > 24 IN: strlcpy
> > 25 IN: up_allocate_heap
> > 26 IN: mpu_log2regionfloor
> > 27 IN: board_autoled_on
> > 28 IN: tiva_mpu_uheap
> > 29 IN: umm_initialize
> > 30 IN: mm_initialize
> > 31 IN: nxmutex_init
> > 32 IN: nxsem_init
> > 33 IN: nxsem_set_protocol
> > 34 IN: mm_addregion
> > 35 IN: mm_lock
> > 36 IN: nxsched_gettid
> > 37 IN: nxmutex_lock
> > 38 IN: nxsem_wait
> > 39 IN: nxsched_remove_readytorun
> > 40 IN: nxsched_add_prioritized
> > 41 IN: up_switch_context
> > 42 IN: exception_common
> > 43 IN: arm_doirq
> > 44 IN: arm_ack_irq
> > 45 IN: irq_dispatch
> > 46 IN: irq_unexpected_isr
> > 47 IN: syslog
> > 48 IN: vsyslog
> > 49 IN: nx_vsyslog
> > 50 IN: lib_syslograwstream_open
> > 51 IN: lib_vsprintf_internal
> > 52 IN: vsprintf_internal.constprop.0
> > 53 IN: strnlen
> > 54 IN: syslograwstream_puts
> > 55 IN: syslog_write
> > 56 IN: syslograwstream_putc
> > 57 IN: syslog_putc
> > 58 IN: __ultoa_invert
> > 59 IN: __aeabi_uldivmod
> > 60 IN: __udivmoddi4
> > 61 IN: __assert
> > 62 IN: _assert
> > 63 IN: up_saveusercontext
> > 64 IN: panic_notifier_call_chain
> > 65 IN: syslog_flush
> > 66 IN: uname
> > 67 IN: gethostname
> > 68 IN: snprintf
> > 69 IN: lib_memoutstream
> > 70 IN: lib_vsprintf
> > 71 IN: memoutstream_puts
> > 72 IN: memoutstream_putc
> > 73 IN: up_dump_register
> > 74 IN: up_getusrsp
> > 75 IN: up_check_tcbstack
> > 76 IN: arm_stack_check
> > 77 IN: stack_dump
> > 78 IN: nxsched_foreach
> > 79 IN: sched_lock
> > 80 IN: sched_unlock
> > 81 IN: reboot_notifier_call_chain
> > 82 IN: up_mdelay
> > 83 IN: board_autoled_off
> >
> > I assume this is unexpected ? If not, I'd appreciate any insights.
> >
> > Thanks,
> > Robin
> >
>
