This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5728: DVFS at 1.5 GHz does not work

Part Number: AM5728

Hello,

We have a custom designed board based largely on the AM5728 eval board. The problem we have is that our application hangs on the custom board but runs well on the eval board.

There are different hang error messages - neon memcpy illegal instruction, pixman neon illegal instruction, dpll set rate timeout, omap drm timeout, etc.

We have isolated the root cause of the problem to running the processor at 1.5 GHz. By default, we have the ondemand governor running and the application hangs within a few minutes. By setting the governor to userspace and limiting the frequency to 1.176 GHz or 1 GHz, the application runs smoothly. Changing the freq to 1.5 GHz causes a hang within 1 minute.

What could the problem be here? Is this a power integrity issue on the MPU rail?

Another observation is that in section 5.5.2 of the datasheet, both MPU and DSP/GPU voltage rails need to track AVS. However, we observe that only MPU voltage changes with frequency and DSP/GPU rail is fixed.

MPU voltages are 1.1 V for 1 GHz, 1.16 V for 1.176 GHz and 1.25 V for 1.5 GHz. The DSP/GPU rail is always fixed at 1.16 V for all frequencies. Could this be causing the problem?

  • Hi Rajat,

    Apologies for not following up on this earlier. 
    Is this issue still open?

    Regards,
    Parth

  • Yes, still open. Any ideas on what we can do to find the root cause?

  • Hi Rajat,

    Can you please confirm the following:
    Which SDK version are you using? Are you working on RTOS SDK or Linux SDK?
    Also, can you please share some details on how are you switching between the frequencies?

    Regards,
    Parth

  • Hi Parth

    We are using Linux SDK 5.03.

    We originally had the ondemand governor active which changes the frequency based on CPU load. When the load is low, there is no problem. As the load increases, the frequency changes to 1.5 GHz and very soon the kernel crashes.

    To workaround this, we set the governor to userspace and that allows manual control of the frequency. Setting the frequency to 1.176 GHz works fine.

    Instructions from: https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Kernel/Kernel_Drivers/Power_Management.html

    My questions are -

    1. Should the DSP/GPU rail voltage be fixed at 1.16V irrespective of frequency?

    2. If yes above, can we conclude that it's the MPU rail that has power integrity issue? Or could be also be one of the other rails?

    I can confirm that we're not running to over-temperature issues. The heat dissipation scheme is pretty good and the temperature die temperature does not exceed 45 deg C at highest load.

  • Hi Rajat,

    Have you probed the voltage of MPU when the frequency reaches 1.5GHz? What is the exact voltage of the MPU rail? It might not be 1.25V due to Smartreflex kicking in & it might be lower than that. So please measure the voltage of the MPU rail when the frequency toches 1.5GHz.


    1. Should the DSP/GPU rail voltage be fixed at 1.16V irrespective of frequency?

    This is typically set in the Boot loader one time. Are you using the DSP/GPU extensively as well?

    If yes you will need to bump up the voltage.

    Is there a chance that you could try on 6.03 version of SDK? This will have 4.19 based kernel.

    - Keerthy

  • Hi Keerthy

    Yes, I've probed the voltage at 1.5 GHz and can confirm that it is 1.25V. However, 2 caveats -

    1. The governor was set to 1.5 GHz fixed not dynamic to measure this. Is the Smartreflex problem expected in this setting as well?

    2. The voltage was measured near the PMIC, not near the processor. Near the PMIC it was 1.27 V. I hope that the sense lines would regulate to 1.25 V at the processor.

    And, yes, both the DSP and GPU are heavily used (video encoding and openGL rendering are going on).

    Unfortunately, I cannot try SDK 6.03. I get some nasty SGX lockup error.

  • 1. The governor was set to 1.5 GHz fixed not dynamic to measure this. Is the Smartreflex problem expected in this setting as well?

    Okay 1.25V since you have measured then its good.

    2. The voltage was measured near the PMIC, not near the processor. Near the PMIC it was 1.27 V. I hope that the sense lines would regulate to 1.25 V at the processor.

    That should be okay as well.


    And, yes, both the DSP and GPU are heavily used (video encoding and openGL rendering are going on).

    I will check on this internally.

    - Keerthy

  • By setting the governor to userspace and limiting the frequency to 1.176 GHz or 1 GHz, the application runs smoothly. Changing the freq to 1.5 GHz causes a hang within 1 minute.

    Rajat,

    Since it runs for 1 minute and hangs one suspect could be thermal reset. Any chance you can check the temperature of the SoC while you run at
    that frequency? Typically when you fix OPP at the highest you can run into thermal issues.

    cat /sys/class/thermal/thermal_zone*/temp

    should give all the temperatures.

    - Keerthy