Advice on JTAG debugging RTEMS for ARM (beaglebone)
james.fitzsimons at gmail.com
Tue Dec 29 04:24:59 UTC 2020
Thanks very much for your reply and advice.
On Tue, 29 Dec 2020 at 11:58, Chris Johns <chrisj at rtems.org> wrote:
> > I'm using TI Code Composer Studio to load the RTEMS application image
> via XDS100
> > V3.0 debugger. If I reset the program counter and step through the
> startup code
> > I see it error on the bsp_fdt_get() call.
> Is this a crash or is an error reported? We should report an error and not
Neither - the processor continues running, just not executing anything
> My IDE isn't copying an fdt image to the expected location the way uboot
> > and so this makes sense. My question is how do other people get around
> this problem?
> > Has anyone else used a similar setup and solved this issue?
> I have not hit this issue but I saw this as a problem with the approach
> taken of
> loading an FDT via the bootloader. It would have been nice to have a way to
> integrate an FDT into the IMFS (or executable) rather than an external
Agreed - this would make it much easier to debug things. Even just having
this as an option
to support debugging would be useful.
> Another approach is to boot using uboot and have it load the FDT and RTEMS
> executable then jump to it. If you can connect via JTAG, reset the
> set a hardware break point on the entry point to RTEMS, and start the
> running from reset it should trigger when uboot jumps to RTEMS. The entry
> is at a fixed address. When the breakpoint is hit delete it and then you
> can set
> further break points in your application.
Thanks for this suggestion - I've managed to get this working pretty much
as you described.
I build the SD card image and boot from that, then connect via JTAG, reset
and break on Init().
It's a pretty clunky process, but at least I have actual on device
debugging working now instead of
having to rely on printf debugging.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users