After making calls using HFP, the device becomes very laggy. What could be the reason?

During initialization, HFP has already been initialized.

After HFP initialization and before making remote calls, LVGL refreshes relatively smoothly.

However, after using HFP for calls, LVGL becomes extremely sluggish.

![000000000000000000000000000000000 00000000000_20000 0 000000 “token”: " 00
00000000000 000000 “token”:

{“intent”:

{“intent”:
\u
communicator", {“user_ocument”, “user_ocument”, “user_ocument”,_user_ocument",user_ocument", “user_ocument”, “user_USER_OBJECT”, "U0000000000UTOR, {"user_OBJECT_USER _USER_OBJECT", "USER_OBJECT_USER_USER, {"should_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER_USER intent_USER_USER_USER_USER_USER_USER USER_USER_MAN_USER_PERSON_USER intent JSON

USER_USER ManitUNCHAT_USER_USER_USER_USER_USER_TEXT_JSON_JSON_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANGONTUN

{“should intent_ intent: 00000000,0000000000000000000000000 000 “token”:”$u0000000000000 “time”: " " "!_0000000 "!00000_000000000000_000000000 "li000 “should_ocument_USER_USER_USER_USER_USER”, “should intent”:_000000000000000000000_USER_USER_USER_USER_USER_USER_TOKEN_USER_USER_USER_USER_USER_USER_USER_TEXT_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG_LANG

This is the LVGL screen refresh effect after running a call, very laggy.

During HFP calls, the audio algorithm consumes CPU resources, thus affecting the performance speed of other functions.

But after the call ends, it still lags and doesn’t recover.

That might be due to audio-related resources not being released successfully. Could you please let us know which platform and software version you are using?

sifli-sdk V2.4 version, HFP example program regarding BT in the example programs

Hello, is there a way to handle this?

Capture a log to check. Generally, audio should be disabled; if no changes were made, this issue shouldn’t occur. If there is an audio_open type=0, as long as there’s a corresponding audio_close type=0 afterward, then it’s properly closed. Also, run the sys_info command before and after to check whether the system has throttled frequency.

image The CPU appears to be normal

8eacc5550706f9039a8bf534e08a3041 audio_open type=0 and audio_close type=0 are available.

Regarding the sys_info command you mentioned, how do I execute it? Do I need to enable any configuration? After I entered it, I was prompted that the command was not found.

32780089-ca2d-4ba8-ae35-6f69a9912f2e

1ddd1b30-4cfa-4175-8d17-ff4509ef4031

I added CONFIG_BSP_PM_FREQ_SCALING=n, but there’s still lag. Looking at the build output, it seems this setting isn’t being applied. Could you please check whether I’ve added it in the correct location?

Check the .config or rtconfigh file under the build_sf32lb_52xxxxx directory. If BSP_PM_FREQ_SCALING is not present, frequency scaling is not enabled. If frequency scaling is confirmed to be disabled, then check the CPU usage to see if any process is consuming high CPU.

Where can this log be seen?

It’s the sysinfo command; run help to see what commands are available.

The main frequency has been reduced to 48MHz. How can this be modified?

483b3a7b-9e87-4a05-9274-f917e962fdbf

The compilation result shows that BSP_PM_FREQ_SCALING is undefined. However, sysinfo indicates that the CPU frequency has been reduced.

The macro cannot control the 52-chip; it’s set to downclock by default. In audio_server.c, when audio starts, it calls the following code to prevent downclocking and sleep:

    rt_pm_request(PM_SLEEP_MODE_IDLE);
    rt_pm_hw_device_start();
    pm_scenario_start(PM_SCENARIO_AUDIO);

When exiting, it calls this to allow downclocking and sleep:

    pm_scenario_stop(PM_SCENARIO_AUDIO);
    rt_pm_hw_device_stop();
    rt_pm_release(PM_SLEEP_MODE_IDLE);

However, after calling pm_scenario_stop(), if no other component prohibits downclocking, the system defaults to downclocking.

To prevent downclocking, you can control it at boot time or via the UI by adding a counter to lock and prevent downclocking. The following scenario types are available:

typedef enum
{
PM_SCENARIO_UI,
PM_SCENARIO_AUDIO,
PM_SCENARIO_RFTEST,
} pm_scenario_name_t;

pm_scenario_start(PM_SCENARIO_UI); // Indicates a request from UI to prevent downclocking
pm_scenario_stop(PM_SCENARIO_UI); // Indicates a request from UI to allow downclocking

These calls must be paired. You must not call start multiple times for the same type.
You can call pm_scenario_start(PM_SCENARIO_UI) once at boot or via the UI to prevent downclocking.
If you later want to allow downclocking again, call pm_scenario_stop(PM_SCENARIO_UI) once.

Calls must be strictly paired—no multiple starts or stops for the same type.
As long as any one scenario type prevents downclocking, downclocking remains disabled.
Only when all scenario types allow downclocking can the system actually downclock.

To save power consumption, you can start when the screen is on and stop when the screen is off.

That’s fine; after pm_scenario_start(PM_SCENARIO_UI), the frequency will no longer be reduced.