Back to the point, this discussion touched important area, lets focus
on how to design a versatile CRC(16/32) API that would keep things
operational and self-compatible, but create a new user selectable
choices/alternatives. That seems the best constructive way forward :-)
Thanks! :-)
Tomek
--
Peter Barada
peter.bar...@gmail.com
.
__start in arm_head.S you'll see code that does some initialization(to
enambe MMU, etc) and jumps to .Lvstart where it setups the stack pointer
to IDLE_STACK_TOP indirect from .Lstackpointer (IDLE_STACK_TOP).
Hope this helps!
On 2/11/25 22:50, Lwazi Dube wrote:
On Tue, 11 Feb 2025 at 18
e understand how to work this out? It is probably
related to the start assembly code (which is not my forte) and perhaps
in the map file?
Context - trying to finish off a boot_image.c function that is copying
a NuttX/MCUboot imgtool.py signed binary over to SDRAM to execute it.
Thanks!
TimJTi/TimH
--
Peter Barada
peter.bar...@gmail.com
bytes on
stack, avoiding this issue (coincidently?). The latest master branch does
not have this issue too, and I’m not sure if it’s guaranteed or not.
Regards,
Neo
--
Peter Barada
peter.bar...@gmail.com
) at
common/arm_switchcontext.c:95/
/(gdb)/
--------
*From:* Peter Barada
*Sent:* Friday, January 24, 2025 9:22 AM
*To:* Tomek CEDRO
*Cc:* Nuttx-dev
*Subject:* [External Mail]Re: GDB can't show QEMU ARM thread call
stack/threads
[外部邮件]
此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存
_start.c:116
#16 0x in ?? ()
(gdb)
Going back I've verified I'm using the advertised instructions in
https://nuttx.apache.org/docs/12.6.0/guides/qemugdb.html for version
12.6 0- which fail to unwind thread call stacks (outside of the current
thread's stack).
I'm focusing on version 12.6 since I've got customer failures in a
Nuttx-12.6 application(network send() gets stuck) - and hoping if I can
get gdb to be fully thread-aware there then I can dump the call stacks
and walk them to best understand the context of the failure.
Thanks in advance!
--
Peter Barada
peter.bar...@gmail.com
n access threads in version 12.8)? Outside of the sparse tags in
git, does anyone have a suggestion on how to best bisect to find where
the issue(s) cropped up(especially since nuttx and apps are in separate
repos)?
Thanks in advance!
--
Peter Barada
peter.bar...@gmail.com
