The only thing I’ve done up to this point with CCS and BBAI64 is write PRU code. After much messing around, I was able to get the PRU C/C++ compiler to compile my code and it seems to deploy to the PRU fine. I am still struggling to get an output pin to twitch from the PRU, but I think it’s pin mode stuff I haven’t done yet. I know I can manually go to the GPIO and set the mode from my experience with the BBB. However I’m trying to reorient myself with dtb overlays, rebuild my dto and get those pins configured at startup. I just haven’t done a lot of dtb work so I’m having to figure that out.
But to your point about CCS and BBAI64, if all you are wanting to do is debug application C-code running in Linux (on Cortex A72), you could use CCS or “vanilla” Eclipse CDT to debug using gdbserver running on the BBAI64 and gdb on the PC.
Since I’ve never debugged a Cortex R, I couldn’t say what it takes to single-step code running in them. However my guess is it’ll require the JTAG connection, OpenOCD and all that stuff mentioned in the debugging thread. OpenOCD is listed as a JTAG device in CCS.
Once OpenOCD is running locally & talking to your JTAG debugging device (the TIAO), then gdb running inside CCS/Eclipse would connect to OpenOCD and start a debugging session. What I have no clue about is the difference in user experience between debugging Linux application code and performing stop-level debugging at the processor level, which is what I’d assume you’d be doing in the Cortex R using the JTAG connection.