Good afternoon,
I am using an STM32G474VE board to control a synchronous buck converter. My initial goal is to implement an open-loop voltage controller and measure the buck converter’s current and voltage signals.
I designed my controller in PLECS and successfully flashed it onto the STM32G474. However, I am encountering issues when using the External Mode to modify duty cycle values in real time. When I enable External Mode and flash the microcontroller, the communication fails, and I receive the following error message:
“Communication error for system ‘BUCK_BO’: Wrong port or no response from target.”
Last week, I performed several tests on the ADC, DAC, and HRTIMER with a switching frequency of 20 kHz, and everything worked perfectly.
For my actual application, I increased the HRTIMER frequency to 136 kHz (with a system clock of 170 MHz). At this frequency, External Mode fails to connect, and the DAC is no longer updated in real time.
Do you have any insights into why these communication and update issues occur at frequencies above 20 kHz?
BUCK_BO.plecs (73.4 KB)
This is a classic CPU overrun issue. In the initial model the CPU’s base task interrupt was 20 kHz. In your updated model it increases to 136 kHz (~7x increase). At the higher frequency CPU cannot complete all the required calculations in the time you have allocated.
See this Support Solutions article for a more comprehensive discussion. Note that some of the diagnostic features mentioned in this article are not available for STM32 target yet.
In your model there is no need to update the control loop at such a high frequency. All protections are done through high-speed analog comparators and everything else is driven by user-interaction via the external mode.
You can decouple the CPU Base Task frequency from the PWM frequency. This is done by:
- Opening the Trigger tab of the HRTIM Master and changing the Repetition counter setting setting from the default value of
1 to N.
- Change the Discretization step size in the Coder + Coder options + Scheduling tab from it’s current value of
1/136e6 to N/136e6.
Since 20 kHz previously worked, one can assume an initial value of N=7 for a 19.4 kHz base task interrupt. The resulting CPU load is ~30%. The switching frequency is still 136 kHz.
BUCK_BO_BL.plecs (75.7 KB)
Good afternoon,
Thank you for your feedback. I will apply your advice as well as the recommendations from the article.
I have another question regarding the External Mode settings when using a SEGGER J-Link. According to your documentation (STM32 Target Support User Manual Version 1.6.1), I need to set the target device name in the “External Mode” menu to 127.0.0.1.
Could you clarify why this specific address is used? Do I need to configure my STM32G4 with this IP address as well?
Please note that I am not using a Nucleo-G474 board, but a custom board based on the same MCU.
The IP address 127.0.0.1 is the localhost IP address. It refers to your computer. The STM32G4 does not need to be configured with this address.
Good Morning,
Thank you for this precision.
I’m reopening this thread because I’m having MCU overload issues again.
In the first post, I was working in an open-loop configuration, and it made sense to divide the frequency at which tasks could run by N.
I am now in a closed-loop configuration, and I need my ADCs to operate at the same frequency as my PWM signal to minimize the risk of spectrum folding of this PWM signal into my current measurement signal.
So I set the “Repeat Counter” value to 1 and enabled multitasking in the Coder settings.
I set task values for each of my control loops:
- Current = approximately 20 kHz
- Voltage = approximately 2 kHz
- Low priority = 20 Hz
With this configuration, the MCU is flashed, but I cannot establish a connection.
I therefore assume that I am overloading my µC.
What can I do to reduce the load on my MCU, given that I cannot adjust the switching frequency of my converter?
Thank you
BUCK_BF_I-V2.plecs (106.6 KB)
Hello,
136 [kHz] is too fast for even simple control loops. I think you will need to move your ADCs and signal conditioning into the voltage regulation task and the current regulation task, which will become your new base task.
In order to minimize the delays between reading the ADCs and processing the obtained data, I would also attach the Control Task Trigger to one of the ADCs in the current regulation task. By doing that, the ADC conversion becomes the event that triggers the interrupt service routine that dispatches the control task on the CPU of the MCU.