TMS320F280049C: Is shadow to active load disabled during shadow write access?

Hi, thanks for the reply. Is that mentioned/explained anywhere in the manual?

I really need something in the documentation to point to to support this for our safety evaluation.

I don't remember seeing this described in the TRM. When the register is being updated at exactly CTR=0 event, the event is already using the register value at the cycle right before that.

Bharathi,

You are the architecture expert, Is my understanding correct?

Nima

Subrahmanya Can you comment on the item above please?

To clarify my question:

The way I understand the process of writing into registers is that the data is invalid during the process or writing. Depending on how long the write access takes I am asking if there is a timeframe where the shadow register to active register transfer could occur during the write access and therefore transfer invalid data.

Let's say I want to write into the CMPA shadow register. I have the register set up to transfer from shadow to active on CTR=0 (Global transfer event for the module). And the CRT=0 event occurs as I write the data. Would it transfer invalid, "in-progress of writing data" into the active CMPA register? Or would it skip the CMPA as it is currently being accessed but still transfer the PRD register? Or would it just ignore the transfer event and delay all shadow transfers for that module until the next CTR=0 event?

Hi,

You don't have to disable the shadow load before the write operation. 
Register contents will not glitch, the newly written contents will be transferred to the active registers on the next event.
But if you overwrite the shadow register in between, the content in the shadow register (which is yet to get into the active register) will be lost.
Usually, an interrupt is taken on CNT=0, and all the shadow registers are updated and these gate loaded into the active registers on next CNT=0 and fresh data can be written to shadow regs.

Thank you for the reply. Could you please tell me where in the documentation this is stated?

I now understand the behavior for this eventuality but the issue popped up in the safety analysis and I need to source the information for the documentation.

Hi,

TRM specifically doesn't have commentary on the question you referred but, general operation of shadow to active loading is described here -
"18.5.3 Operational Highlights for the Counter-Compare Submodule"

In general, it's advisable to avoid such boundary conditions of loading due to software uncertainty I mentioned above - if you always want the CMPx registers to be loaded from shadow to active on the following cycle.

I don't find this answer useful. The purpose of the shadow register is to prevent errors due to asynchronous SW access. If I need to run interrupt controlled access to prevent possible glitches then it does not serve its function.

I have not seen this module glitch once in 12 years of use. I know that the condition I described does never occur. Therefore I either got lucky (and I am never lucky) or the module is designed to prevent glitching. It has to be the second but I need a reference to prove this for the SW analysis. If you do not know where to find that reference, please refer this issue to another developer.

The shadow is useful for many scenarios.

But here is what we are talking about,

IF AT RANDOM TIMES you write to let's say CMPA and TBPRD who are both shadowed and are using CTR=ZERO. One of the times, lets say you write to the CMPA, another register, then TBPRD back to back. You write to CMPA at CTR=PRD-1, the other register at CTR=0,  and TBPRD at CTR=1, then the values for CMPA and TBPRD who are supposed to go toghether will not both be loaded in the same cycle. 

Hi,

Peter Kozlowski1 said:

The purpose of the shadow register is to prevent errors due to asynchronous SW access.

Purpose of shadow register is to not disturb the active register values that are in the process of being applied to the output generation. Shadow registers act like a buffer so that active values are changed as and when intended (beginning of PWM cycle etc.).
Also, updating shadow register any time doesn't result in any glitches - as you are in shadow mode of operation. I've mentioned the same above "Register contents will not glitch, the newly written contents will be transferred to the active registers on the next event."
So, you do not have to be concerned about glitches in this case. 

I don't understand what you just wrote. I also don't understand what you are even referring to. You literally wrote:

"IF AT RANDOM TIMES you write to let's say CMPA and TBPRD who are both shadowed [...] then the values for CMPA and TBPRD who are supposed to go toghether will not both be loaded in the same cycle. "

So the benefit of the shadow register is that values that are supposed to go together will not go together? Do you maybe want to rephrase that?

I know what the shadow register is and what it does. It allows simultaneous updates and prevents glitching on asynchronous access due to invalid data. I JUST NEED A REFERENCE. 

""Register contents will not glitch, the newly written contents will be transferred to the active registers on the next event."
So, you do not have to be concerned about glitches in this case. "

I know and understand that. But I work in the car industry and have a safety review. I can't go to BMW and tell them "We wont have glitches. A guy on the internet told me." I need a reference in an official document.

The problem I described is an issue in controllers without shadow registers because the active register can be accessed during a compare event. So the question is on the safety analysis list. And the TRM documentation does not mention what happens during simultaneous access. I really just need a reference document that I can attach to the safety review documentation.