R5F Cores Real-Time Debugging

Hello,

Sorry for the delayed response. This thread was assigned to me while I was on vacation.

MERT YIGIT said:

The customer wants to debug the r5f cores on the J784S4 EVM in real time using CCS 12.8.

Support for R5 real-time memory accesses requires specific device support which is currently not supported with all devices. The dependency is a combination of hardware and software. I will bring this thread to the attention of the device experts who can comment further.

Thanks

ki

Hi,

Enabling CCS on the J784S4 EVM is documented at: 7. CCS Setup for J784S4 — Processor SDK RTOS J784S4

To my knowledge there are no additional CCS features which are enabled, outside of what is described there and/or within CCS v12.4.   

Regards,

kb

Hi Ki,

Is there a hardware restriction for real-time memory access to R5 cores?

Thanks.

Hello,

The R5 core has some real time non-intrusive debug aids but it will be lacking some which are common in TI DSPs.  The DSPs have dedicated real time modes where high priority marked interrupts can continue to run or instructions can be injected into open execution slows. These are not features the Cortex-R5 has. Some M cores MCUs also have some unique real time features.

The R5's TCMs can be read at run time without stopping cores as they are dual ported. A person must use the slow SOC access path and address (see TRM memory map) instead of the fast locally programmed TCM address.  As the system and local addresses are different, if a you want to see variables' symbols, an offset is needed at symbol load or a tool like TRACE32 fixes it up with the 'dapremap' command.  The R5's also offer ETM trace which allows run time trace.  The ETM unit can do on the fly inspection to allow things like 'break' if a variable has a certain value.   External memories like OCMC or DDR can also be viewed at run time using the SOCs' DAP (coresight axi-ap with a CBA bridge).  This allows run time monitoring of external memories.  This can work well enough if the R5 has its memory attributes for those registers as non-cached or write-through.  The DAP cannot see into the R5 cache so if copy-back is in use the value may be stale as seen by the debugger.  Some customers have tried periodic cache flushes to make non-intrusive debug possible.

I gave a quick try to insert a break point on the fly with a debugger on my desk.  This did appear to work.  I'll attach a short video.  The R5 does export some of its internal state on paths the debugger can get at.  The R5 is 'limited' compared to what the 'A72' on the platform can do in this regard.  For example the R5 PMU counters are only accessible at run time through for the 2 ETM counters,  the others PMU counters require a processor halt, where on the A72 they all can be read at run time.  The R5 TRMs from ARM do describe these features.

Each debug tool will have different levels of support based on what a given CPU's hardware exports and the SW driver used.