TMS320F28335: APWM duty cycle jump to 100%

Hi Howard,

How frequently the issue is happening? Is it possible to share full Ecap configuration code?

Hi,

Hi, it happens only when the main power stage controlled by C2000 is working.

If only power on F28335 and output APWM, there will not be the problem.

So we think it's not caused by the software configuration but by the influence of the main power stage.

Any possible cause for F28335's APWM not working properly? We need a direction to find out how to solve the problem.

Howard,

I am not sure if I understood when it works and when it does not work. Can you please elaborate both cases little more?

I agree with you that probably it is not due to configuration but it is better to review the configuration and then looking for other debug steps.

F28335  is used to control an inverter in a PV system. When the inverter is working(high voltage 800V DC BUS high current 50A), there will be such problem.

If no high power is applied, we only power F28335 board, it will not have such problem.

Howard,

Can you ask the customer to scope both supplies for the MCU in addition to the eCAP output? This way we can see if an event on the supplies is causing this.

Jha,

we haven't captured the supply along with eCAP output, but with the current signal(which will rise when eCAP jump to 100%).

We monitor the power supply at MCU's supply pin.

3.3V analog- yellow, current- green, we can see the supply is stable when current rises.

3.3V digital- yellow, 1.9V digital- purple, we can see the supply is stable when current rises.

1.9V analog- yellow, we can see the supply is stable when current rises.

We have no direction on how to debug such issue.

Hi Howard,

I have highlighted a dip on the scope shot you provided. Which supply is that and what is the magnitude of that dip?

hi

One is PV input voltage, and the other is PV input current. Because the duty cycle suddenly changes to 100%, the current rises and the voltage drops. Now the focus is on why it suddenly changes to 100% and then returns to the original value

Hi Lee,

Ok. I think something is accidentally modifying the CAP registers in your code and causing this. Can you look through your code to see where writes to the CAP registers take place? Please look through all the source files in your project. You can just use Ctrl+F and search. Start by focusing on interrupts.

Configuration code is in a few lines, and it is confirmed repeatedly

SysCtrlRegs.PCLKCR1.bit.ECAP4ENCLK = 1;
GpioCtrlRegs.GPAPUD.bit.GPIO27= 0x1;
GpioCtrlRegs.GPAMUX2.bit.GPIO27 = 1;
ECap4Regs.TSCTR = 0x0;
ECap4Regs.CTRPHS = 0x07D1;
ECap4Regs.ECCTL2.bit.CAP_APWM = 1;
ECap4Regs.ECCTL2.bit.APWMPOL = 0;
ECap4Regs.ECCTL2.bit.SYNCI_EN = 1;
ECap4Regs.ECCTL2.bit.SYNCO_SEL = 0;
ECap4Regs.ECCTL2.bit.TSCTRSTOP = 1;
ECap4Regs.CAP1 = 10000;

these all

The program has limited the duty cycle to 0.8, which should not be changed to 1. Is ECAP unstable

Lee,

Which code is setting CAP2?

In AD interrupt control, CAP2 is refreshed in real time

Please provide that interrupt code

Lee,

Based on all the information you have provided so far, something is changing CAP2 value in your application. The ECAP won't just change by itself. I was initially under the impression CAP2 was statically set in your application but since you mentioned it's being updated in an interrupt, that is the source of your issue. There are some debug steps you can take to isolate this.

1. In the interrupt code that updates CAP2, add a condition to set a variable flag if the value being written to CAP2 is not 0.8 duty cycle. This will tell you if that ever happened.

2. Statically set CAP2 to 0.8 duty cycle i.e the interrupt does not update CAP2 and see if the problem goes away.

I set a flag bit in the interrupt. If CAP2 is greater than 0.8, software set it to 1. I monitor the flag bit, but it has not changed to 1. Therefore, the software does not give a value greater than 0.8. In addition, the weak current to a fixed duty cycle, the pulse is no mutation

Lee,

Did you check all the CAP registers? Particularly CAP4 which is the shadow for the duty cycle? If not, please check them also in the interrupt to see if they are changing.

I didn't understand your last point. When you statically set CAP2 to 0.8 duty cycle, did the problem go away or not?

I don't understand what you mean. The program only uses cap1 and CAP2. Cap1 is fixed and determines the switch cycle. CAP2 refreshes every control cycle, and cap4 is not used

Lee,

CAP3 and CAP4 are shadow registers. Any accidental write to them will affect the output whether or not it is being used. Can you answer my question from above?

Frank Ankapong said:

When you statically set CAP2 to 0.8 duty cycle, did the problem go away or not?

It doesn't work. Refresh cap4 in the program at the same time, and the duty cycle suddenly jumps to 1. Due to the limiting, I think there is something wrong with this peripheral

Hi Lee,

Sorry, I am still not getting an answer to my question. When you statically set CAP2 to 0.8 that is if you don't update CAP2 in the interrupt, does the issue go away or not?

Don't you think this way of communication is too slow? A simple question may not be communicated for a month; Given a fixed duty cycle, the duty cycle will not change if the high voltage is not connected and only 5V is connected; But no matter what voltage is connected, the monitoring does not exceed the limit. Is the peripheral not stable enough。

Hi Lee,

We shouldn’t jump to the conclusion that the ECAP is unstable because based on your description of the problem, there is an external event “high voltage is connected” that is somehow causing this. In addition, the F28335 device has been out for a very long time and we have had no reports of “unstable” ECAP. That is not to say it is not possible. Let’s look at other possible causes first.

What we know so far is that there is an external event “high voltage is connected” that is causing this to happen. We have to narrow the debug on this. Please give as much information as possible when you say “high voltage is connected”. How does the system change when this happens? i.e any software changes? any hardware changes? etc.

The description of these days is very clear. When the voltage is connected to 24 V, give a fixed duty cycle, and the pulse is normal; When connected to high voltage operation, the pulse duty cycle occasionally jumps from a certain value to 100%, and then immediately returns to the original value; In the program, the maximum duty cycle limit is 0.8, and no exception is found in the monitoring. The refresh value is relatively stable and does not exceed 0.8; Later, according to your suggestion, the shadow register cap4 is updated at the same time, which has no effect; And measured the power supply 3.3V and 1.9V, the power supply is normal, there is no jump, what else need to pay attention to? You said high voltage connection, IO external pull-down resistance

Lee,

Can you provide a schematic or drawing of the design with and without the high voltage connection?

No way to provide. One is that only the control board is connected with weak current, the other is the strong power on the whole product. I think it is still necessary to pay attention to the peripheral problems. As APWM, this peripheral will be forced to jump under any circumstances. You can also communicate with Chinese technical support. My program has been restricted and processed in multiple ways. No abnormality is found in power test. How to deal with it

I did an experiment today. The comparison value of duty cycle is accumulated automatically, which is greater than 8000, and it will accumulate from 1000. When 8000 changes to 1000, there is a full duty cycle

Hi Lee,

I didn't fully understand your last post on the accumulation experiment. So you accumulated 800 and what changed? How many accumulation iterations was this? Also was this with the "high voltage" setup connected?

Please explain again.

Please look at the photos of the program. It has nothing to do with the voltage. There is something wrong with the peripheral

So clear, don't you understand

Let Zou Howard explain to you. I think I described it very clearly

Lee,

1. When the switchover happens from 8000 to 1000, have you already checked what was written to CAP2 to make sure it was 1000?

2. Have you tried other combinations e.g: increment to 7999 and transition to 1000; increment to 8001 and transition to 1000; increment to 7999 and transition to 999 etc.

3. What is generating the interrupt that this update happens in? What is the interrupt frequency?

1. Confirmed; 2. Other combinations have been tried, only when 8000 changes to 6000, there will be no duty cycle of 100, indicating that CAP2 changes a little bit normally; 3. My program is accumulated in the sampling interrupt, frequency 15K

Lee,

1. Ok.

2. You mean the problem only appears when 8000 changes to 1000? No other combination causes this?

3. What is the trigger for this interrupt. Is it the ECAP itself?

4. I am thinking an immediate period update on a state change of the ECAP is maybe causing this. Try another experiment: Run the same accumulation code you have above but instead of updating CAP2, update CAP4. Updating CAP4 will shadow load into CAP2.

You should be very familiar with your products. It's not convenient for us to communicate with each other, and we can't communicate directly with chat software. This kind of simple logic can be verified by you with the chip. After all the conditions are said over and over again, you can verify them in the company, and then you will know it all