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. > >
