U-Boot uncontrollable debug stepping

I've been having some issues debugging U-Boot. I believe it is due to a RAM configuration error, but I would like to get some clarity on it.

My methodology for testing is below, and is based on these instructions for the BeagleBone Black

1. Load board with no memory/image
2. load u-boot-spl.bin to the SRAM memory via JTAG at the proper address specified in processor manual (TI AM5728, so address 0x40300000) and load u-boot-spl ELF symbols
3. Set PC register to the start address of U-Boot-SPL (0x40300000)

4. Run SPL, and pause after I receive a message such as this one:

5. At this point I know that U-Boot has relocated from the SRAM to the DDR3 RAM due to spl_relocate_stack_gd() being already called.

6. Load U-Boot via JTAG, the PC automatically changes to address 0x80800000 due to having the context of the relocation.

From here I would resume the application to get to the U-Boot console and get the gd->relocaddr from bdinfo, but even single stepping into the program results in U-Boot becoming unresponsive, and the PC moving to address 0x0000000C.

My guess is that this is because the SDRAM was not configured correctly, resulting in an erroneous read, considering that the first instruction is a branch, which could result in the erroneous PC value.

The trouble is that when I try this with a TI AM5728 EVM, with the known-correct RAM configs, the same thing happens. But when I start the EVM with a SD card that only has u-boot.img and MLO, I reach the U-Boot command line.

Am I going crazy with the notion that this could be the RAM? Since I have evidence of a working RAM configuration for the same SoC doing the same behaviour, or is there something else that I am missing? printf()'s don't seem to work, and enabling the DEBUG macro does not print anything to console, either.