TMS320F28069: TBPRD and TBPRDM not as expected

Howard,

Howard Zou said:

TBPRD read reflect the shadow register value, right? So in fact TBPRDM=700?

TBPRDM read reflect the active register value, right? So in fact TBPRD=1401?

In shadow mode:

• Reads to TBPRDM indicate the active value for TBPRD.
• Reads to TBPRD indicate the shadow register value.

So, yes it seems like when the values were sampled the active value is 1400 and the next value to be loaded on a shadow load event is 700.

Howard Zou said:

But we can’t find why TBPRD active value is 1401 since we never write that value into TBPRDM.

Writing to TBPRD or TBPRDM should write update the shadow register's value.

I think it is most likely that you are reading the values above at a point that is synchronous to the PWM's period. At the time of read the active TBPRD value is 1400 and the shadow value is 700. Some time after you read the values, but before the Shadow load event TBPRD or TBPRDM is written to updating the shadow value to 1400. Then the next shadow to active load occurs and 1400 is populated into the TBPRD active register.

Now there is a chance that this is a one off device failure.

Next steps:

1. Verify that this occurs on multiple devices
   1. If it occurs on multiple devices this is then most likely a SW bug and we should begin cutting down the code to the simplest case which shows the issue.
   2. If it does not occur on multiple devices with the exact same binary file, then we should submit the device for failure analysis if the customer wishes to find the root cause.

Regards,
Cody 

Cody,

we think that we find the problem:

PWM1 will generate SYNC signal to PWM2 to load TBPHS to TBCTR.

At start-up, PWM1 TBPRD=1400, up-down count mode, SYNC signal is generated when TBCTR=0. PWM2 TBPRD=1400, TBPHS=1400, up-down count mode.

PWM1 and PWM2 are 180° phase shifted according to the configuration.

Then we change the TBPRD of both PWM1 and PWM2 to 700, PWM2 TBPHS=700. Since it's in shadow mode and shadow to active happens when TBCTR=0 and PWM1 counts to 0 first, and then PWM1 TBPRD active=700, at this moment SYNC signal is generated and PWM2 TBCTR will load TBPHS=700, and PWM2 TBPRD active is still 1400 because TBCTR never count to 0, TBCTR will count up from 700 to 1400 and then count down, the next SYNC signal will make TBCTR load 700 again.

It explains why we will see PWM2 TBPRD(active)=1400, TBPRD(shadow)=700, and explains why we can get the plot below:

But we also happens to meet waveform below:

PWM2 counter will count between 700 and 2100. My understanding is: PWM2 TBPRD is updated to 700, TBPHS=700, with PHSDIR= count up, when TBCTR=TBPHS=700, it will ignore that TBCTR=700 and then still count-up.

But if that's the case, it doesn't comply with the original setting. Because at start up, we have PWM2 TBPRD=1400, TBPHS=1400, up-down count mode, PHSDIR=count up. The waveform is still symmetrical, which means that when TBCTR=1400, it count down instead of count-up.

So we need your confirmation of:

1. when in up-down count mode, if we set TBPHS=TBPRD and set PHSDIR=1 to count up, but TBCTR=TBPHS=TBPRD will make it count down, this is conflicted, then which one will take priority?

2. And with SYNC between PWM1 and PWM2, is it possible that the TBCTR will still vary by like (0.1TBCLK delay or ahead) instead of integer number of TBCLK defined by TBPHS？If it could be ahead or delay, then we may explain why we could see 2 different kinds of waveforms.

Howard, on number 1 I have reached out to the design team. I suspect based on your observations that TBPRD reversing the counter direction is most likely the lowest priority. We will see what their reply is.

On number 2 I don't think this is possible, it should always be closed to an integer value.

Regards,
Cody 

Cody,

any update for number 1?

No. Someone has been assigned to look into it. I have not received a timeline estimating when this will be completed.

Regards,
Cody