Hi Matias, Yes, it could be a nice idea.
I need to re-test and write the documentation! BR, Alan On 8/27/20, Matias N. <mat...@imap.cc> wrote: > It would be cool to add a guide for this in the documentation (could be > under "guides" in principle). > > Best, > Matias > > On Thu, Aug 27, 2020, at 18:29, 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 >> >
