On Tue, Aug 11, 2020 at 4:30 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > On 11/08/2020 11:40, Richi Dubey wrote: > > (gdb) continue > > Continuing. > > > > Thread 1 hit Breakpoint 2, _ARMV4_Exception_data_abort_default () at > > /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70 > > If you hit this break point, try to use > > bt > > and then set a conditional break point to the offending function, reset > the target, and run again. >
Yes, the backtrace is most important at this point, because you are still trying to figure out how you got to the exception. It depends on the correctness of the program call stack though, so you may on occasion find the bt is corrupt/fails. In such cases, you may need to set breakpoints during the RTEMS initialization/startup sequence. The boot_card() is a good place to start from in those cases. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
