Thanks Bartok. Seems, as usual, I am Mr. DumbHead as I am already using a CortexA5.svd file and do, indeed, see Cortex registers. But IO am not 100% convinced the svd is totally right so I'm trying to track one down for the SAMA5D2 family.
What I can't do is trace the cause of an exception. The earliest entry in the call stack is: arm_vectordata@0x200081a4 I am using that address, at least, to pinpoint the file at issue from the .map output, but no joy fixing it yet! I am now looking at the PX4 debug files you suggested but some of the options aren't liked by my VS Code environment/extensions and they are not recognised by GDB (e.g. "backtrace" or "showtasks"). I can't manually type these commands in either so it suggests the set up isn't thread or task aware as I'd sort of twigged. I will press on and hopefully find a solution to make the debugging environment more comprehensive. Thanks for taking the time to reply :) >From: Bartek22 <bartol2...@gmail.com> >Sent: 03 March 2023 07:00 > >Take a look at PX4 project on github. I work with this setup with my own >projects with nuttx and everything works great. They are generating some >files from cmake so take a look at platforms/nuttx directory and >CMakeLists files inside and add .svd files for your mcu and everything >should work. >Best regards, >Bartek > >czw., 2 mar 2023, 20:24 użytkownik Tim Hardisty <t...@hardisty.co.uk> >napisał: > >> I have been using VS code with a Segger Jlink for debugging so far but >> am struggling to find the cause of a problem in a driver I'm writing >> and I think the VS Code debug setup may be lacking. >> >> Before I spend time getting openOCD installed and following the >> various guides for that, with NuttX, that exist, has anyone used VS >> Code to more thoroughly debug NuttX (threads, memory >> exceptions/errors) rather than just relying on breakpoints? >> >> Thanks, >> >> TimH >>
