The TMS570 targets are interesting for RTEMS because they have space-grade/qualified variants and have heritage, i.e. Ingenuity helicopter on Mars. But that target is really difficult.
As for RTEMS BSP variants, the internal SRAM version is easy and can be send to the target by mainline OpenOCD. But the size of program is really limited. For development, we have used mainly TMS570LS3137 with startup standalone system-less code built by CCS which has initialized safety functions and SDRAM controller and then it wait for program load by OpenOCD. The some version of that application is there https://github.com/hornmich/tms570ls3137-hdk-sdram. It offspring of our project for Porsche and EATON, unfortunately based on FreeRTOS and CCS which provided broken LwIP and required lot time to make that mess working. The related thesis there but in Czech language, sorry.
Then we have two setups with running applications from Flash, one with bootloader based on FreeRTOS which allowed sending of images over XCP on Ethernet and another where RTEMS BSP is compilled with TMS570_USE_HWINIT_STARTUP enabled when RTEMS started directly from boot in Flash.
The flashing of the externally build binary is possible by CCS and modified OpenOCD.
With CCS we have used for command line invocation on Linux something like this
#! /bin/sh
# This script executes LoadTI for DSS Linux
export LOADTI_PATH=$(dirname $(which $0))
${CCS_SCRIPTING:=/opt/ti/ccsv5/ccs_base/scripting/}/bin/dss.sh $LOADTI_PATH/main.js $@
Where provided main.js written in JavaScript has invoked flashing in Eclipse style with prepared TMS570LS3137.ccxml file. I can try locate these files and more but it is 10 years ago, so it would require more time. The Flashing of external binary from GUI was possible as well.
We have managed OpenOCD to work with the target but the code has been based on other developer fork and the main problem is that the stub send to target to process actual flashing has been based on Texas Instruments F021 flash library because there was no documentation of required registers and algorithms. And that library has been closed source so no go for OpenOCD mainline. My patches and OpenOCD variant for TMS570LS3137 is available there https://cmp.felk.cvut.cz/~pisa/tms570/. I have compiled old OpenOCD version successfully some years ago. But it can be problem today.
But I have spoken with Texas Instruments representatives about these difficulties on this year Embedded World and they informed me, that their policy changes and that they support OpenOCD for some of their, probably newer chips. But there is not direct replacement for Hercules family in the fact and they plan to produce it still and there is chance to do something with this. As it would help my colleagues at https://www.elektroline.cz/ as well, because they are using some Hercules chips and would be happy to flash them from ARM GNU/Linux based tester on the production line, I can try to contact people at TI if there is chance to get information and join forces. The tools used with our TMS570 OpenOCD fork can be found there https://github.com/AoLaD/rtems-tms570-utils. The related thesis documenting development of RTEMS TMS570 BSO, again in Czech sic, there.
But on the other hand, I would suggest to consider alternative to development cycle based on chip flashing for each iteration. The Flash memory of these chips has really limited number of erased cycles specified, about one thousand if I remember well. So use of the Flash erase and load for each test could lead to unusable board in relatively short time.
I have interest in this target so I try to provide some knowledge and hints as my time allow. But cannot promise much till the end of semester, we have 160 students enlisted in the course.