Gustavo,
Adding that line to my config appears to have done the trick! The info
for the work queue threads still appear a little garbled, but maybe that
is normal? Here is the output
(gdb) info threads
Id Target Id Frame
* 2 Thread 603982356 "" (Name: Idle Task, pid:0, RUNNING) up_idle ()
at common/arm_idle.c:63
3 Thread 939531824 "" (Name: init, pid:3, WAIT_SEM) 0x00000000 in
?? ()
4 Thread 939525520 "" (Name: hpwork, pid:1, WAIT_SIG) 0x00000000
in ?? ()
5 Thread 939528544 "" (Name: lpwork, pid:2, WAIT_SIG) 0x00000000
in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 939525520)]
#0 0x00000000 in ?? ()
I did a quick test and was able to set breakpoints and step through the
CAN example app. I could also see that thread just fine. Thank you very
much for the pointer!
- John
On 8/27/20 5:12 PM, Gustavo Henrique Nihei wrote:
Hi John,
you can follow the guide from Sony's wiki page and use OpenOCD master
branch from upstream repository.
Then you just need to configure OpenOCD to enable thread awareness by
adding the following line to you config file:
"stm32h7x.cpu0 configure -rtos nuttx"
Please, find attached an example OpenOCD config file for the STM32H7
single core CPU.
Best regards,
Gustavo.
On Thu, Aug 27, 2020 at 5:47 PM John Rippetoe
<jrippe...@roboticresearch.com <mailto: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.
Thanks,
John
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.
--
Gustavo Henrique Nihei
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.
