I always wondered if we could improve the hardfault debugging experience somehow. One option is to extend the gdbinit script to do this as a command. I'm not sure if it is a failproof procedure though, as the LR sometimes simply contained the address of other instructions inside the hardfault handler. I think the issue is that you need to halt execution right before all registers are touched in the handler. The problem I always found is that at this point it doesn't mean execution arrived there due to a hardfault as this is also used for context switches (so placing a breakpoint there is of no use).
On the other hand, recent changes to add a backtrace to asserts on ESP32 could maybe be extended to handle hardfaults (doing the aforementioned procedure in code and try to recreate the callstack and print to console). Best, Matias On Thu, Dec 10, 2020, at 10:10, David Sidrane wrote: > Hi Brennen, > > I have not tested with vscode in a bit. But the issue for me before was the > edit ability of registers on IP blocks and CPU. Ben may be referring to the > hard fault debugging technique I presented at the NuttX conference 2 years > ago. It is a simple cut and paste from the LR to the IP regs in the eclipse > GUI, and IIRC a ton of typing in VS code or read only. Has that improved? > > David > > -----Original Message----- > From: Brennan Ashton [mailto:bash...@brennanashton.com] > Sent: Wednesday, December 09, 2020 5:59 PM > To: dev@nuttx.apache.org > Subject: Re: about IDEs and dev boards > > Marlar > With the plugin that I linked you should be able to nice debugging without > having to use two different environments. Just don't use the native vscode > debugger from the c++ it has long standing issues with remote targets. > > Ben is there a reason you don't use it for hardfaults? I'm not sure I quite > understand what you would run into with that. > > --Brennan > > On Wed, Dec 9, 2020, 5:30 PM Marlar Chan <marlar.c...@ntu.edu.sg> wrote: > > > Dear Ben, > > Is there any setup guideline for Nuttx debuggig with VSCode (normal > > use) and Eclipse (Hard faults)? > > > > Best Regards, > > Marlar > > ________________________________ > > From: Disruptive Solutions <disruptivesolution...@gmail.com> > > Sent: Wednesday, December 9, 2020 6:16 PM > > To: dev@nuttx.apache.org <dev@nuttx.apache.org> > > Subject: Re: about IDEs and dev boards > > > > VSCode (normal use) and Eclipse (Hard faults). > > > > STM32 stack (nucleos, blackboards, etc) and own reference board(s). > > > > Hardware as extra tools (logic analyzer, scope, seggers, st link, etc) > > > > And just having fun to use NuttX and the results one can achieve..... > > Still > > mind blowing!!! > > > > Ben > > > > Op wo 9 dec. 2020 8:39 a.m. schreef Marc Rosen <ma...@zeitcontrol.de>: > > > > > > > > Am 04.12.2020 um 02:54 schrieb Matias N.: > > > > Hi, > > > > I was wondering what IDEs do you use with NuttX and what is your > > > preferred dev board (can be more than one). > > > > I'm curious since I have used QtCreator for long time now and > > > > generally > > > works well, but it has some quirks. > > > Jetbrains CLion is the IDE i use. It is not that great with Makefile > > > projects and debugging but it is getting better. > > > And it works well if you also use some of their other dev tools and > > > ides. > > > > And on hardware side I always favored STM32 boards (with embedded > > > debugger) but after getting into nRF52 I found > > > > it to be much easier to work with and seems a very well designed SoC > > > from the users perspective. The "mux (almost) any peripheral to any pin" > > is > > > great (any other chip does that?). > > > > > > > > Best, > > > > Matias > > > Mostly AVRs here, the ones too small for Nuttx, and STM32. Usually > > > custom boards. > > > > > > regards, > > > Marc > > > > > > > > ________________________________ > > > > CONFIDENTIALITY: This email is intended solely for the person(s) named and > > may be confidential and/or privileged. If you are not the intended > > recipient, please delete it, notify us and do not copy, use, or disclose > > its contents. > > Towards a sustainable earth: Print only when necessary. Thank you. > > >
