Advice on JTAG debugging RTEMS for ARM (beaglebone)

[James Fitzsimons]

Hi Chris,

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
> crash.
>

Neither - the processor continues running, just not executing anything
useful.

> My IDE isn't copying an fdt image to the expected location the way uboot
> would,
> > 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
> load.
>

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
> processor,
> set a hardware break point on the entry point to RTEMS, and start the
> processor
> running from reset it should trigger when uboot jumps to RTEMS. The entry
> point
> 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.

Cheers,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20201229/98865887/attachment.html>