SPRUHJ1I January 2013 – October 2021 TMS320F2802-Q1 , TMS320F28026-Q1 , TMS320F28026F , TMS320F28027-Q1 , TMS320F28027F , TMS320F28027F-Q1 , TMS320F28052-Q1 , TMS320F28052F , TMS320F28052F-Q1 , TMS320F28052M , TMS320F28052M-Q1 , TMS320F28054-Q1 , TMS320F28054F , TMS320F28054F-Q1 , TMS320F28054M , TMS320F28054M-Q1 , TMS320F2806-Q1 , TMS320F28062-Q1 , TMS320F28062F , TMS320F28062F-Q1 , TMS320F28068F , TMS320F28068M , TMS320F28069-Q1 , TMS320F28069F , TMS320F28069F-Q1 , TMS320F28069M , TMS320F28069M-Q1
The first tick rate defines the main rate at which InstaSPIN as a whole will be executed from the end of conversion ISR. When this tick rate is greater than one, every time InstaSPIN is executed there will be a check in an internal counter, and if this counter hasn't reached the tick rate value, it will return from InstaSPIN execution. There is no code executed inside InstaSPIN library other than the check of this counter. Figure 10-4 shows how the tick counter is checked in the ISR.
Figure 10-5 shows InstaSPIN execution with a tick rate of 2.
Figure 10-6 can also be represented as a software execution clock tree. Notice how the highlighted block has a value of two, causing a divide by two in the software execution clock tree.
There are two main reasons why a tick rate from the interrupt to the controller might be higher than 1:
For example, if the PWM frequency is 50 kHz, if no hardware decimation is used (which will be discussed later in this document) the end of conversion ISR is at the same rate, 50 kHz. There needs to be enough time in 1/50 kHz = 20 µs to execute all the functions. If the functions within the ISR take 30 µs, then:
Execution time > ISR Period → 30 µs > 20 µs
This will lead to interrupt overrun, causing ADC samples to be overwritten, and control timing will also be affected.
In cases where the interrupt is shorter than the execution time, it is safe to use different ISR to CTRL tick rates if the following guidelines are taken into consideration.
Verify there is enough time in the interrupt to execute InstaSPIN.
This is because when executing InstaSPIN in the interrupt service routine there has to be enough time to avoid conversion overrun. For example, if an ISR hasn't been serviced, and a second one comes in, the first one was completely lost, and the timing is affected. A good example is shown in Figure 10-7, when the ISR has enough time so that InstaSPIN completes execution with no ISR overrun.
Figure 10-8 shows the software execution clock tree representation of this timing diagram.
Another example using decimation rates with a higher PWM frequency, leads to a shorter ISR, but even though one ISR is not serviced right away, it eventually does with no ISR overrun (Figure 10-9). This would work ok as well, without affecting performance.
On the other hand, if the PWM frequency is setup too high, the end of conversion interrupt might be overrun by a second interrupt. An overrun condition is undesirable since it will cause a complete set of ADC samples to be lost. In addition to that, an interrupt overrun causes a complete interrupt to be missed and as a result of that, the timing of the InstaSPIN state machine will be wrong, since it depends on the periodicity of the interrupts. Not keeping a good timing schedule in the InstaSPIN library causes issues such as angle estimation not being accurate, speed estimation being off, speed and current controllers not performing as desired, just to list a few. The following example shows an interrupt overrun condition. Keep in mind that InstaSPIN execution is the same, what we are changing is the PWM frequency (hence the end of conversion interrupt frequency) and the decimation number. The first example of interrupt overrun is without decimation, so all of InstaSPIN executed at every interrupt (Figure 10-10).
Figure 10-11 shows the software execution clock tree values of this timing diagram.
Notice how after a few interrupts a complete interrupt is overrun. The problem with this is that now the timing is shifted, so internally in the InstaSPIN state machine and controllers, timing is now slower than it really is.
Another example is using decimation rates. In Figure 10-12 a decimation rate of 2 is used, and as you can see, even using decimation rates we have the limitation of interrupt overrun.
Figure 10-13 shows the software execution clock tree values of this timing diagram.
Set frequency of InstaSPIN to at least 10 times the electrical frequency of the motor.
The second aspect to be considered when setting PWM frequency and ISR vs. CTRL tick rate is the number of InstaSPIN runs versus the electrical frequency of the motor. This is because when running in a closed loop system, where field oriented control depends on an electrical angle, there should be enough estimated angle updates per electrical cycle to keep the field properly oriented. An analogy of this requirement is when an AC signal needs to be digitally sampled. This is related to Nyquist frequency, where a frequency just above the sampled frequency is enough to avoid aliasing. In a field oriented control system Nyquist frequency is not enough to provide an efficient motor control. The recommended InstaSPIN run rate is at least 10 times of the electrical frequency of the motor. In order to know the electrical frequency of a motor, that is, for a Permanent Magnet Synchronous Motor (PMSM) we need to know the speed and the number of poles.
For example:
Pole Pairs: 4
Speed: 7500 RPM
Electrical Frequency: Speed in RPM * Pole Pairs / 60 = 7500 * 4 / 60 = 500 Hz
Minimum Recommended InstaSPIN run rate = 10 * Electrical Frequency = 5000 Hz
In this example, we have chosen an ISR vs. CTRL tick rate of 3, resulting in an ISR frequency of 5000 * 3 = 15000 Hz.
Figure 10-14 shows the resulting waveforms from this example.
Figure 10-15 shows the software execution clock tree numbers for this example.