SPRUHJ1 User guide

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

9.2.4 Practical Example

A case example is shown next, where the CPU loading is restricted by the application and the PWM frequency requirement is fixed. For example, consider the following parameters for our case study:

InstaSPIN Execution time only checking the tick rate counters: 2.7 µs

FAST estimator execution time: 12.9 µs

InstaSPIN Execution time without the FAST estimator: 14.2 µs

Total of InstaSPIN with FAST: 27.1 µs = 12.9 µs + 14.2 µs

PWM Frequency requirements: 50 kHz (TISR = 20 µs)

A typical example where such a high PWM frequency is needed is when the motor has a very low inductance. Having a low PWM frequency would create undesirable current ripple due to the low inductance. A solution for these applications is to have a higher PWM frequency. In the example a 50 kHz PWM frequency is required.

The first configuration we should try is with the ISR to CTRL, CTRL to CURRENT and CTRL to EST all to 1, so that we get the best performance. If we try these tick rates to one, we get Figure 10-20.

Figure 9-20 Tick Rates Timing

As can be seen from the timing diagram, the interrupt is shorter than what needs to be executed, so this will lead to interrupt overrun, hence undesirable behavior.

T_ISR < T_InstaSPIN → 20 µs < 27.1 µs → this leads to ISR overrun, hence unexpected InstaSPIN results

Figure 10-21 represents the values of this timing diagram in highlighted boxes.

Figure 9-21 Tick Rates Software Execution Clock Tree

Notice how the interrupt time is not enough to execute InstaSPIN at the same rate and it never catches up with execution. In fact, after a few interrupts there are missing interrupts, which will cause unexpected results. A solution to this problem is to use the tick rates so that the FAST estimator runs at a lower rate compared to the rest of InstaSPIN. In Figure 10-22, let's see if we can solve the overrun problem with a CTRL vs. EST tick rate of 2.

Figure 9-22 CTRL vs. EST Timing - Tick Rate = 2

In this case, two interrupts have to be considered to measure timing since there is a tick rate of two being used for the estimator, and as can be seen from the diagram, the time for 2 interrupts is shorter than what needs to be executed without and with FAST, so this will lead to interrupt overrun, hence undesirable behavior.

2 * T_ISR < (T_{InstaSPIN without FAST} + T_{InstaSPIN with FAST}) → 40 µs < 41.3 µs → unexpected InstaSPIN results

Figure 10-23 represents the values of this timing diagram in highlighted boxes.

Figure 9-23 CTRL vs. EST Software Execution Clock Tree - Tick Rate = 2

As can be shown, every time InstaSPIN with FAST is executed there is an increasing latency. In three cycles we see how this latency increases from 0 µs, to 1.3 µs and then 2.6 µs. We can predict that in a few more cycles there will be an interrupt overrun, since the execution time is not catching up with the interrupt rate.

The solution for this case study is to increase the CTRL vs. EST tick rate even further, to three, so that the latency is back to zero every InstaSPIN cycle as can be shown in Figure 10-24.

Figure 9-24 CTRL vs. EST Timing - Tick Rate = 3

In this case, three interrupts have to be considered to measure timing since there is a tick rate of three being used for the estimator, and as can be seen from the diagram, the time for 3 interrupts is longer than what needs to be executed without and with FAST, so this will avoid interrupt overrun.

3 * T_ISR < (2 * T_{InstaSPIN without FAST} + T_{InstaSPIN with FAST}) → 60 µs > 55.5 µs → expected InstaSPIN results

The available CPU for other tasks outside the ISR or other lower priority interrupts can be calculated as follows:

3 * T_ISR - (2 * T_{InstaSPIN without FAST} + T_{InstaSPIN with FAST}) = 4.5 µs

CPU % left = 100 % * 4.5 µs / 60 µs = 7.5 %

2806x MIPS left = CPU % left * Max MIPS = 7.5 % * 90 MIPS = 6.75 MIPS

Figure 10-25 represents the values of this timing diagram in highlighted boxes.

Figure 9-25 CTRL vs. EST Software Execution Clock Tree - Tick Rate = 3

Another solution to this problem is to change the ISR vs. CTRL tick rate to 2. Considering an InstaSPIN run of 2.7 µs when only the tick counters are checked, we have Figure 10-26. As can be seen, selecting a tick rate of 2 for the ISR vs. CTRL tick rate is enough to avoid any conversion overrun.

Figure 9-26 ISR vs. CTRL Timing - Tick Rate = 2

In this case, two interrupts have to be considered to measure timing since there is a tick rate of two being used for the controller (CTRL), and as can be seen from the diagram, the time for 2 interrupts is longer than what needs to be executed without and with the controller, so this will avoid interrupt overrun.

2 * T_ISR < (T_{InstaSPIN without CTRL} + T_{InstaSPIN with CTRL}) → 40 µs > 29.8 µs → expected InstaSPIN results

The available CPU for other tasks outside the ISR or other lower priority interrupts can be calculated as follows:

2 * T_ISR - (T_{InstaSPIN without CTRL} + T_{InstaSPIN with CTRL}) = 10.2 µs

CPU % left = 100 % * 10.2 µs / 40 µs = 25.5 %

2806x MIPS left = CPU % left * Max MIPS = 25.5 % * 90 MIPS = 22.95 MIPS

Figure 10-27 represents the values of this timing diagram in highlighted boxes.

Figure 9-27 ISR vs. CTRL Software Execution Clock Tree - Tick Rate = 2