TMS320F280049C: Enable Silicon Real-time Mode

Hi Champs,

Do you have any update?

Thanks and regards, Johnny 

Dear Champs,

I have same question.

Do you have any update?

Wayne

Dear Johny, Wayne,

Firstly apologies for the delayed response, since I was out on personal emergency for almost a week.

There are override bits on top of DBGM which is generally handled by the CCS drivers internally.

Mostly there could be issues with the GUI translation handling the override bit's. Will talk to the CCS drivers team and get back on this. 

Ideally, it should not be updating the watchwindow in one of the scenario. You can very well disable the memory window refresh to achieve the same today momentarily.

Dear Karthikeyan

I just want to confirm if there is any difference or risk if we just enable "continuous refresh" on Watch and memory windows and use it like the real-time debug.

If it can use it in this way, it's easier and more friendly than what we used to do by enabling Silicon Real-time Mode (DBGM bit).

That is, if the underlying CCS drivers simplify these procedures, it's still useful for us.

Please keep us posted.

Thank you.

Wayne

Dear Wayne,

That's precisely the override is supposed to do for Debug watch window updates to ignore the DBGM.

I will keep you posted once I get hold of the CCS folks with more details.

Johnny Chen said:

Without this step, I could still run the code and look up for updating values in memory browser and register by enabling continuous refresh.

Note that older versions of CCS required you to explicitly (and manually) enable real-time mode for this feature. More recent versions of CCS have this functionality enabled by default. It is likely that the workshop was written with an older CCS In mind.

As for the difference between having Silicon Real-Time Mode enabled or not, I believe it is with regards to the real-time handling of interrupts. I'll need to confirm this.

Thanks

ki 

Dear Ki,

That is a good clarify for me knowing that the older versions of CCS required to do it.

Thank you for confirming whether it  would regard to real-time handling of interrupts.

This will probably help users a lot. Thanks !

BR, Johnny 

I'm still awaiting confirmation from engineering. I'll let you know as soon as I hear anything.

Thanks

ki

Dear Ki,

1) What does critical section mean? 

Can the user assign some memory sections to be critical or to be non-critical manually in the .cmd file?

All registers are NOT critical sections, right?

2) Is my understanding below correct?

For non-critical sections, both behaviors of "polite" and "rude" are same, and there is no risk.

For critical sections, only "rude" can access memory/registers at the cost/risk of a few more cycles.

Wayne

Ki said:

No, there is always a small overhead with real-time accesses. Those few cycles rarely have any impact in non-critical sections of code. It is only in critical sections that it *may* make a difference. Hence why those sections are specified as "critical".

Actually, after re-reading your question, you are correct - only "rude" access can access the target memory/register when in a critical section. But to clarify - both polite and rude mode accesses always have that small cycle overhead. The polite vs rude difference is when the debugger can make those accesses.

Dear Ki,

Thank you for your information.

Dear Johnny,

See if you have any further question.

Wayne

Yet 90% of the time Rude interrupt is mandated to re-write Flash object.  Unless user first Pauses RealTime Silicon before CCS build changes the object.  Otherwise the logic of debug gets all narky and like a good watchdog barks when object changes are made while real time silicon is enabled CCS v9.3. 

I find it less troublesome to pause real time silicon prior to re-building project as to include changes to the object during next flash update.