Hi John, You are welcome! Nice to know that everything is working.
BR, Alan On 8/28/20, John Rippetoe <jrippe...@roboticresearch.com> wrote: > It turns out I had already modified the offsets in nuttx_header when I > took a quick stab at this a few months back. I guess it has been so long > that I forgot. Thank you very much for pointing me in the right > direction on this Alan. > > I will definitely be giving your new gdb script a try Masayuki. Thank > you for all of your work on NuttX debugging! > > - John > > On 8/27/20 8:16 PM, Masayuki Ishikawa wrote: >> Hi Alan and all, >> >> Alan's comment is right. >> >> Because openocd-nuttx needs to know about tcb_s members in NuttX to >> access >> them. >> and both values must be the same. Otherwise, openocd-nuttx does not work >> correctly. >> >> However, this procedure is sometimes annoying (even for me) if we are >> debugging >> multiple targets having different configurations. >> >> So, I implemented .nuttx-gdbinit which is a gdb script and it does not >> rely >> on openocd-nuttx. >> Actually, we can do thread-aware debugging for the NuttX simulator on >> x86_64 for >> which we can not use openocd. >> >> Of course, we can do thread-aware debugging for the NuttX for Cortex-M >> boards >> with **normal** openocd as well. >> >> The script is still experimental and not merged into the NuttX upstream >> and >> it has to >> be used with gdb supporting python. For Arm environment, we have to use >> arm-none-eabi-gdb-py >> instead of arm-none-eabi-gdb. Actually I'm using the following gdb to >> debug >> Cortex-M boards. >> >> $ arm-none-eabi-gdb-py --version >> >> GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) >> 8.3.0.20190709-git >> >> So if you are interested in the script. Please try the following git. >> >> $ git clone -b gdbinit_for_nuttx >> https://github.com/masayuki2009/incubator-nuttx >> >> On Fri, Aug 28, 2020 at 6:59 AM Alan Carvalho de Assis >> <acas...@gmail.com> >> wrote: >> >>> Hi John, >>> >>> If the tcb_s values returned are the same from openocd header, then >>> you don't need to do anything. If they are different you need to >>> update, otherwise it will not work reliably. >>> >>> BR, >>> >>> Alan >>> >>> On 8/27/20, John Rippetoe <jrippe...@roboticresearch.com> wrote: >>>> Alan, >>>> >>>> Thanks for sending this! Gustavo's suggestion of adding the '-rtos >>>> nuttx' flag to my config did the trick, so maybe this process isn't >>>> needed anymore? >>>> >>>> - John >>>> >>>> On 8/27/20 5:29 PM, Alan Carvalho de Assis wrote: >>>>> Hi John, >>>>> >>>>> On 8/27/20, John Rippetoe <jrippe...@roboticresearch.com> wrote: >>>>>> Hi everyone, >>>>>> >>>>>> I recently jumped back into working on the FDCAN driver for the >>>>>> STM32H7 >>>>>> and have something working which I would like to test further. In >>>>>> doing >>>>>> so, I was hoping to easily debug with GDB through OpenOCD, but am >>> having >>>>>> some issues with the necessary setup. So far I have compiled and >>>>>> tested >>>>>> the upstream master of OpenOCD, master of the Sony OpenOCD fork, and >>>>>> a >>>>>> third build that merged the latest upstream OpenOCD commits into the >>>>>> Sony fork. With all three, I am only ever able to see the currently >>>>>> running thread (nearly always IDLE) when running the "info threads" >>>>>> command. >>>>>> >>>>>> So my question is, does anyone have any experience getting this >>> working? >>>>>> I looked through the mailing list and saw a few messages regarding >>>>>> this >>>>>> very thing for different architectures. I've also dug around on the >>>>>> internet to help me piece together what needed to be done to get this >>>>>> working. I initially got the impression that as long as OpenOCD >>> supports >>>>>> your chip, thread aware-debugging should be possible, but now I'm not >>> so >>>>>> sure. I modified nuttx_header.h within OpenOCD with the correct >>>>>> offset >>>>>> values as noted here >>>>>> >>>>>> https://micro-ros.github.io/docs/tutorials/advanced/nuttx/debugging/ >>>>>> >>>>>> That didn't change anything, unfortunately. I also thought it was >>>>>> possible this step was no longer needed based on the Sony fork's wiki >>>>>> page >>>>>> >>>>>> https://github.com/sony/openocd-nuttx/wiki >>>>>> >>>>>> The monitor commands listed there gave me "invalid command name" >>>>>> errors >>>>>> when loading my nuttx binary. >>>>>> >>>>>> Any help on this would be greatly appreciated. >>>>>> >>>>> I tested it some years ago and Masayuki gave me some important >>>>> instructions: >>>>> >>>>> 1) You need to include "-rtos nuttx" in the target create line of the >>>>> /usr/local/share/openocd/scripts/target/stm32f4x.cfg to use with >>>>> stm32f4discovery board: >>>>> >>>>> target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap >>>>> $_CHIPNAME.dap -rtos nuttx >>>>> >>>>> 2) Add this code to your .gdbinit >>>>> >>>>> define print-offset >>>>> print /x &((struct tcb_s *)(0))->pid >>>>> print /x &((struct tcb_s *)(0))->xcp.regs >>>>> print /x &((struct tcb_s *)(0))->task_state >>>>> print /x &((struct tcb_s *)(0))->name >>>>> print /x sizeof(((struct tcb_s *)(0))->name) >>>>> end >>>>> >>>>> Then start gdb with nuttx to load the symbol. >>>>> >>>>> $ arm-none-eabi-gdb ./nuttx >>>>> >>>>> Before connecting to the target, obtain the symbol offsets in tcb. >>>>> >>>>> (gdb) print-offset >>>>> $1 = 0xc >>>>> $2 = 0x80 >>>>> $3 = 0x1a >>>>> $4 = 0xcc >>>>> $5 = 0x20 >>>>> (gdb) >>>>> >>>>> Then you need to put those value inside the header file: >>>>> openocd/src/rtos/nuttx_header.h replacing the existing value: >>>>> >>>>> /* default offset */ >>>>> #define PID 0xc >>>>> #define XCPREG 0x70 >>>>> #define STATE 0x19 >>>>> #define NAME 0xb8 >>>>> #define NAME_SIZE 32 >>>>> >>>>> Compile and install again openocd with the right values. >>>>> >>>>> I hope it help you! >>>>> >>>>> BR, >>>>> >>>>> Alan >>>> CONFIDENTIALITY NOTICE: This communication may contain private, >>> confidential >>>> and privileged material for the sole use of the intended recipient. If >>> you >>>> are not the intended recipient, please delete this e-mail and any >>>> attachments permanently. >>>> >>>> > CONFIDENTIALITY NOTICE: This communication may contain private, confidential > and privileged material for the sole use of the intended recipient. If you > are not the intended recipient, please delete this e-mail and any > attachments permanently. > >
