ePWM spikes

Dear Bharathi,

Thank you for your reply. Spikes occur every 1.5s, which is extremely slow to be the trigger signal for an oscilloscope. So what we do is use one of our transducers for DC voltage and "read" the spikes at a PC. Unfortunately, 3V is too low for our 150V voltage transducer, so we can only monitor the output of the optodriver. It took us about 6 months to investigate:

1) Do spikes really exist, or is it just noise at the monitoring equipment.

Yes, they exist. We have verified it with different approaches, but ... you can even hear them at high power output.

2) Is it just an issue with the optodriver?

No. Output of both PWM and GPIO has exactly the same specifications in terms of current capability and voltage level (3V). Using exactly the same cable and hardware and making sure that this is not local EMI on the board (using shields, grounding etc), we confirmed that spikes only exists with the ePWM. Except if ePWM and GPIO do not have exactly the same current or other capabilities. Need your input in this one.

3) Are the spikes created at specific chopping frequencies or duty cycles.

No. We have checked various carrier frequencies, clock divider values and duty cycles. They always happen at 1,5s. Only magnitude may change, marginally.  At the "magnified" opto-driver output the duty cycle is set at 50%. At a first glance it looks like it remains at 50% at all times. However, the sampling time is not so small to let us notice any marginal difference (e.g. a change to 49%). It definitely stays inside bounds though.

Any help is highly appreciated,

Panagis

Subrahmanya Bharathi said:

Hi Panagis Vovos,

Did you monitor the signal at the output of the F28335 device?
Do you observe spikes or any abnormality at that stage?
I think you mention figure 1 and 2 as the output of the optio-driver.
When the spikes occur is the duty cycle in the expected range or out of bounds?

- Bharathi.

Dear Bharathi,

We try to connect the +3.3V supply to the Oscilloscope. According to the manual we can find it at P2,P4,P8 etc, but all of them require a jumper setting (JR2, or JR4). Is this what you mean or can we probe it somewhere else anyway?

Thanks,

Panagis

Dear Bharathi,

We have some very interesting results for you! We have tapped our monitoring equipment on the +3.3V line (pin 45, P2 connector on eZdsp F28335 board). We have taken two snapshots from the 3.3V line voltage, but this time >>>using exactly the same pin<<< for GPIO and ePWM operation (pin 11 of P8, which is the GPIO2 and EPWM2A pin) for the chopping modulation of our dc/dc converter. In other words we just loaded two different software without touching the hardware: one operating the pin as GPIO and the other as EPWM.  As you can see on the snapshots, there are spikes only on the case that the pin is operated as ePWM. In the other case, you can only see a rather clear 3.3V line (any small ripple is due to the low sensitivity of our 600V dc transducer connected to the board's ADC monitoring the +3.3V line). Therefore, we are now confident (due to your help) that it is clearly a problem with the board and not with our setup. Mind you that the spikes appear only when there power on the dc/dc converter increases beyond a limit, let's say 300W. You can also see that in the first snapshot (power increases gradually and reaches 300W after 6s that the spikes start appearing).

Any help would be VERY appreciated.

Thank you,

Panagis

Edit: When I say "there is something wrong with the board" in my previous post  I do not mean that there is something wrong with the specific board, but generally with the ePWM powering the pin at any eZdsp f28335. As I have mentioned in a previous post, we have noticed exactly the same spikes in two other brand new eZdsp F28335.

Hi Panagis,

These are interesting results. Thanks for checking this. 

- Do the spikes you observe match with the spikes that you see at the opto driver output? i.e. are these same spikes propagating to opto o/ps which you mentioned earlier?

- So, the glitches are coming just because you switched from GPIO switching from CPU to EPWM switching. Are any other chip outputs switching simultaneously? Are there any glitches from power line coupling into IC power supply?


-Bharathi.

Dear Bharathi,

We have performed all the tasks you suggested and here are the results:

"Do the spikes you observe match with the spikes that you see at the opto driver output? i.e. are these same spikes propagating to opto o/ps which you mentioned earlier?"

Yes, we believe they are. We went through monitoring them, again, and visually they look similar. Unfortunately, we cannot monitor them simultaneously, but they "look" the same in frequency, relevant magnitude, number etc.

"So, the glitches are coming just because you switched from GPIO switching from CPU to EPWM switching. Are any other chip outputs switching simultaneously? Are there any glitches from power line coupling into IC power supply?"

In the past we used the same dsp to monitor things (using ADC) and produce the modulation pulses (ePWM or GPIO). If I understood your question well, when ePWM was used we had two chips working at the same time (ePWM and ADC). Today, we used one F28335 dsp in order to monitor things and another F28335 dsp in order to produce the modulation pulses. So, we noticed exactly the same glitches on the monitoring DSP when ePWM was used at the other DSP, but no glitches when GPIO was used instead of ePWM. Thus, it seams like the number of chips working at the same time has no effect whatsoever. We have also tried to use ePWM to feed our optodriver, having GPIO working but not connected to anything. We had glitches again, as expected. 

In all tests, when glitches appear at the 3.3V line they also appear at the +5V. However, we monitor glitches on the 230V power line only when we use the same dsp to monitor 230V and produce modulation for our converter. We do not see any glitches when we use different DSPs to monitor the line and produce modulation pulses. Therefore, we believe that now it is obvious that the glitches exist inside the board only and not on the power line. That is why we "see" them when we use the same board to monitor and modulate. Also, those glitches appear in the board even when we supply power to the dsp from a battery/ups system (so there is no connection to the grid for the dsp).

Any better picture now???

Thanks a grant,

Panagis

Dear Bharathi,

The eZdspTM F28335 is powered by an external 5-Volt only power supply. By reading the technical reference of the board I understand that it uses a TPS767D301 to produce the +3.3V and +1.8V required. I do not see a second regulator for the externally supplied +5V, so I assume that it feeds directly any +5V circuits on the board (the +5V power supply is provided with the board; it is regulated and provides current up to 3A). I cannot see in the manual any way that I could feed the +3.3V externally. The TPS767D301 is soldered on the board and connected directly to any other circuit using the tracks of the board.

I have measured the current drawn from the pin. The results are identical whether the pin is used for ePWM or for GPIO to perform the modulation on the converter:

PSU off (for ammeter testing purposes): 0 mA

PSU on, but no software loaded (idle): 3.34 mA

After loading and running modulation software: 9.80 mA

With power fed in the converter (so that the 1.5s spikes appear): 9.80 mA

As you notice, not only there is no difference between the GPIO and ePWM current, there is also no difference when spikes appear.

At this point, maybe I could share our thoughts about this issue:

Fact 1: Spikes appear EXACTLY every 1.5s when sysclock divider=1,, 3s when sysclock divider=2 etc.

It seams like something "different than usual" happens at the ePWM (or the CPU in conjuction with the ePWM) every 225 million cycles. Maybe the number of cycles depends on some other parameter, but we can keep the fact that it happens exactly every some cycles. Do you know what this may be?

Fact 2: Spikes appear only when the pin is used for ePWM.

Even if the converter setup and modulation remains exactly the same, there are no spikes when the pin is used as GPIO output. Also the current drawn in the two cases (GPIO and ePWM) is exactly the same, so it does not look like there is some power supply insufficiency in one of the two cases. Also, we have tried to use one DSP to monitor and another to do the modulation, but spikes continued to appear in the monitoring DSP, so we can exclude the possibility that the path ending at the ePWM pin runs closely to some other circuits and causes EMI or something to the ADC. But this does not exclude the possibility that it runs close to some other CPU paths, "synchronizing" every 1.5 s with some other paths. Do you have any information about this possibility?

Fact 3:

Spikes also appear in the 5V and 3.3V lines.

Can it be that a ground path runs closely to the ePWM? But then why spikes appear every 1.5s and not every time a pulse is produced? It is not right. Is there some test we can run to exclude the possibility that all this is caused from EMI? Then we could focus on what happens "differently" in the board every 1.5s.

Thank you,

Panagis

Subrahmanya Bharathi said:

Hi Panagis,

Thanks for the data.
what is the LDO used for 3.3v and 5v generation on board?
Is it possible to feed 3.3v and 5v externally? I mean, from an external power supply?
Can you also measure the current drawn in each of these two (EPWM and GPIO) case?

-Bharathi.

Hello Bharathi,

The switching (carrier) frequency is set at 750Hz, now. However, the period of spikes is indifferent (1.5s) as long as the divider=1. We have run tests for 20kHz, 10kHz, 2Khz and spikes appear every 1.5s. Exactly the same carrier frequecies achieved with divider=2 result to spikes of 3s period. Therefore, it looks like there is some kind of connection with the CPU clock.

I don't exactly understand what you mean by closed loop system. Do you refer to our control method or to some "hardware-in-the-loop" setup? Excuse my ignorance of this terminology. Currently, we have removed all other blocks in our simulink and left only 1 ePWM block. Control-wise it is an open loop chopper with a constant 0.5 duty cycle (mind you, we do not use the chopper module, but set the period and Comperator values in the ePWM block accordingly in order to achieve the 0.5 duty cycle). Let me know if I did not fully answer your question.

We use a second F28335 in order to monitor this slow phenomenon, using a ADC block. 

Thanks,

Panagis

Dear Bharathi,

Did you have any news from your EMI expert? Of course, we are still struggling with the spikes every 1.5s...

Thanks,

Panagis

Dear Fulano de Tal,

How can it be a dead band issue every 1.5s? By the way, our converter has a dead-lock safety circuit that doesn't allow any simultaneous leg-firing, just in case something goes wrong with the modulation from the DSP...

We are working for more than 5 years with TI's DSPs on power converters. We have sensitive monitoring equipment (probes, oscilloscopes, analyzers, transducers etc.) which are capable of giving every bit of detail required. We are noticing the "1.5s spikes" for two years now and we have concluded that the problem is beyond our setup.

Please read the conversation above. There is a whole sequence of tests we have gone through with Bharathi, leading us to believe that it is something wrong with the DSP. We have ended up that this may be an EMI issue within the DSP. Do you want to organize a skype meeting with us, so that we can show you the application, the set-up, the connections, everything, so that you can investigate the issue in more detail and provide step-by-step help, like you are virtually here? Anything, that would help us escape from this deadlock would be highly appreciated. Our research is in full standstill... 

Thank you,

Panagis

Panagis, I was suggesting that it could be a deadband issue, not that it definitively is.  The magnitude of the spikes made me think it could be.  I understand that it seems that it is related to the DSP itself.  Maybe there's physically something wrong in the silicone inside.  I can tell you for a fact though, that the F28335 has been used in many power converters, one of which I have written the firmware for.  I've also used the F28335 in HIL platforms, and this issue does not exist.

Here's one thing you can try.  Use a F28335 controlCARD.  It may be something wrong with the eZdsp boards themselves, and not necessarily the DSP chip.

Dear Fulano de Tal,

Thank you for your reply. I have to apologise for the tone of my previous message, but it seemed as we went back three months in pursuing an answer to the 1.5s curse.

From your message I understand that you suspect that the problem is indeed with the paths from the ePWM to the output pin (since the GPIO does not cause such an issue when using tha pin ). 

I have read in the description of the ControlCard that "All of the C2000 controlCARDs use the same 100-pin connector footprint to provide the analog and digital I/Os on-board controller and are completely interchangeable. " Does this mean that we can use any pin for any purpose? Also, is the ControlCard compatible with Simulink and CC3.3. (the only combination working with the F28335)? If the answer is yes to both questions, then ...

Changing the platform of the F28335 indeed may prove that this is the reason. However, this is not so easy to implement:

a) We cannot purchase the board at the distributor's price (reaching Greece at 150+ euros, from the 70$ original price in the US).

b) Even if we could, bureaucratically it would take 6 months to complete the purchase.

c) We already have 6 eZdsps. Can't easily trash that stock, even if we test the new platform and it works...

So ideally, we would like to find the solution for our eZDSPs, but imagine that we do purchase one more board from TIs and still not finding the answer. Can you ask one of your distributors to lend as the board for 6-months, so that we can run the tests and simply see if this is the reason of the problem? That, would be indeed helpful.

Regards,

Panagis

Hello Javy,

Since the spikes appear every 1.5s (for the f28335, it is ~1.2 for the faster f28377d), they are too slow for an oscilloscope to trigger. We could still see them clearly on the oscilloscope, but it was almost impossible to capture properly without triggering. Therefore, we used the ADC of another, independent and powered from an isolated power supply, f28335. We used the SCI to transmit the readings to a PC running Simulink.

You do not get the spikes, as TI support staff doesn't, because you run a low power application. If you use it for a high power converter then you get those spikes. Mind you that, producing the same pulses from the same pin, but using GPIO, creates no spikes. This means that it has something to do with the path from the peripherals to the pin (GPIO vs ePWM). ePWM path >probably< runs in parallel with some soisy path. Supply path?

We are planning to create some small converter, so that TI can reproduce the issue with the proper code ran on eZdsp f28355 or the f28377D control card (as we do).

Good luck,

Panagis 

Dear Jianwei,

We use the standard 6n137 optocouplers, with separate driving circuit. There is perfect galvanic isolation. Common practice for such power circuits, nothing special. We noticed that spikes appear when our power circuit feeds power. We did not manage to clarify if the main factor is current or voltage. We have the feeling it is a combination (power).

Answering to your questions:

1) Did you run the control card alone to see if spikes still exist? 

Yes. They do not.

2) Did you try to supply the optocoupler (the 'next-stage' circuit) with a constant voltage to observe if these spike are still there? Or you generate a PWM signal using function generator to simulate the control card and connect it to the optocouple to check if spikes are still there?

We even run the optocoupler with a ... battery, as we started getting crazy with isolation! We printed a separate board for the optocoupler + driver and fed it from the battery or laboratory power supply. Again, spikes from the DSP pin, when used as ePWM. The same pin created no spikes when the same pulse train was created from the same pin, when used as GPIO! When we used the pulse generator to create (for the third time) the same pulses, there were no spikes on the pulse train. Mind you, that for all these experiments we used isolation for the power supply of the DSP, just to make sure that noise passed from the common supply.

We have never faced such a problem before. The only solution seams to be the creation of a power circuit that creates this issue and send it over to TI to recreate the problem using their boards and labs. This is our net step.

Best regards,

Panagis

It is possible that you already have it, but is there a diode clamp on the gate signals to limit pulse levels to supply voltage? I do understand that this is not a solution to your problem anyway, since it does not deal with the source of the spikes. I will say that this is indeed an interesting problem and I would like to see what is the cause.

Hi Panagis,

Thanks for the detailed and interesting supply.

I don't have constructive suggestions now. 

However, you can try to connect a buffer to the ePWM pin before it is connected to the optocoupler. ePWM pins ===> buffer====>optocpuler===>IGBT/MOSFET driver.

Another possible guess can be directed to the IGBY/MOSFET drive supply. This is a critical issue when designing power converter. Reasons can be any of them, who knows. You can try use different optocoupler, if possible, Just change one module on your circuit and test it. Trial and error.

I hope this may help.

Good luck.

Javy

Panagis,

I couldn't open all of your simulink blocks because it needs a library that I haven't. So opened it up with notepad and look inside it. Please try these. I don't know whether they help, but I hope.

1) In your simulink model options -> solver -> fixed step size is auto. Do not let this matlab to decide, decide the time step of your own (like 0.00001) Make the sample time of all your simulink block same with this value.

2) When I open your target configuration block (in tool chain automation tab), I can see that you enabled optimization with level 3. Do you really need these much optimization? Turn it off, if you don't need it. Sometimes it will cause your code to misbehave.

3) I believe your problem is with epwm module settings and it is somewhere below.

(I opened your simulink model with notepad++ )

periodUnits "Clock cycles"
timerSource "Specify via dialog"
timerPeriod_clk "15000"
timerPeriod_sec "0.0001"


phaseActiveEnable "Specify via dialog"
phaseDirection "Count up after sync"
phaseActive "0"
clockPrescale "4"
HSclockPrescale "1"
ePWMxAStatus on
CMPAUnits "Clock cycles"
CMPASource "Specify via dialog"
CMPAValue_per "50"
CMPAValue_clk "7500"

REDperiod "0"
FEDperiod "800" (make this zero, if you don't need it!)

Try to change this values in your simulink model and observe the output. I hope you can find the root cause of your problem.

Hakan

Dear Hakan,

I am sorry for the late reply, but we wanted to be sure we have exhausted all possibilities. Here are the results per your guidance:

1) We have set the time step to 0.0001, which is the sampling time used by our model. We noticed no difference.

2) We have removed optimization completely and noticed no difference. Then we removed all linker and compiler options and used default settings, again no difference. Then we attempted to change optimization to "faster runs" from "faster builds", but again we noticed no difference. 

3) That was the most time consuming part. In our Simulink model, FED was set to 800, BUT the deadband unit was disabled altogether. What we did is to enable deadband, set FED=0 and disable deadband again. We checked by enabling and disabling the deadband unit that FED is kept to 0, just in case this setting is maintained, even if the whole deadband unit is disabled (long shot). No difference again.

We then attempted to change all other settings suggested (or disable them or change them to other values that could work), but again we noticed no difference. 

We only verified that PWM clock frequency affects spikes. But this is something we have noticed in the past too. Here is the relation between PWM frequency and spikes period of appearance:

30 kHZ --> 0.55s

20 kHZ --> 0.84s

10 kHz --> 1.67s

5 kHZ-->1.67s

and remained 1.67s for lower pwm frequencies.

Now, we are working on building a simple power circuit that will reproduce the problem and send it over to TI for testing.

However, I had an idea. Is it possible for you or someone else to provide me with the simplest code of all in .out format for CCS 3.3 and the 28335, that produces 5khZ pulses with 50% duty cycle at ePWM3A? We are not very familiar with the process of building the code, but we know how to load .out files. Then I could load it over to the DSP and  verify that this is not a MATLAB/Simulink issue (i.e settings).

Thank you for your time, anyway,

Panagis Vovos

Dear Hakan,

We use two types of boards: eZdsp f28355 and f28377D control card. Both of them create exactly the same issues with spikes on power circuits. The only difference is that the faster 28377 creates spikes 150/200 of the period that the f28355 creates the spikes, following the CPU ratio of the two boards. If you have any of the two boards and can provide us with this simple .out file then we could eliminate the possibility that the problem is caused by some Simulink parameter or bug. 

Thank you,

Panagis

Hello Hakan,

Thank you for your help, anyway.

If there is anyone out there that has these few lines that do the ePWM for our boards it would be extremely helpful.

Panagis