<div dir="ltr"><div dir="ltr"><div>Hi Chris,</div><div><br></div><div>Thanks very much for your reply and advice.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Dec 2020 at 11:58, Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I'm using TI Code Composer Studio to load the RTEMS application image via XDS100<br>
> V3.0 debugger. If I reset the program counter and step through the startup code<br>
> I see it error on the bsp_fdt_get() call.<br>
<br>
Is this a crash or is an error reported? We should report an error and not crash.<br></blockquote><div><br></div><div>Neither - the processor continues running, just not executing anything useful. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> My IDE isn't copying an fdt image to the expected location the way uboot would,<br>
> and so this makes sense. My question is how do other people get around this problem?<br>
> <br>
> Has anyone else used a similar setup and solved this issue?<br>
<br>
I have not hit this issue but I saw this as a problem with the approach taken of<br>
loading an FDT via the bootloader. It would have been nice to have a way to<br>
integrate an FDT into the IMFS (or executable) rather than an external load.<br></blockquote><div><br></div><div>Agreed - this would make it much easier to debug things. Even just having this as an option <br></div><div>to support debugging would be useful.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Another approach is to boot using uboot and have it load the FDT and RTEMS<br>
executable then jump to it. If you can connect via JTAG, reset the processor,<br>
set a hardware break point on the entry point to RTEMS, and start the processor<br>
running from reset it should trigger when uboot jumps to RTEMS. The entry point<br>
is at a fixed address. When the breakpoint is hit delete it and then you can set<br>
further break points in your application.<br></blockquote><div><br></div><div>Thanks for this suggestion - I've managed to get this working pretty much as you described. <br></div><div>I build the SD card image and boot from that, then connect via JTAG, reset and break on Init().</div><div>It's a pretty clunky process, but at least I have actual on device debugging working now instead of <br></div><div>having to rely on printf debugging.<br></div><div> </div><div>Cheers,</div><div>James<br></div></div></div>