MCU-PLUS-SDK-AM243X: API to disable LPSCs and PLLs

Hello Joe,

My suggestion is that we should not touch the PLL settings of A53 core. Since  PLL settings can't be modified by the user .

You can just power off the A53 core by using the SCI client API.

Recently we faced some issues with controlling power OFF  the A53 core when we called directly the SCI client.

Please call the SCI API with out any code and see if you are able to power off the A53 core.

If it it does not work out, try with the code below. This code forcefully powers off the A53 Core 0 irrespective of its state.

 /* PSC0 MDCTL register for A53_0 (0x400A00 + 4 * 22)*/
    uint32_t mdctrl_addr=0x400A58;
    uint32_t mdctl=HW_RD_REG32(mdctrl_addr);

    /* Reset the Module Next Field (4-0) */ 
    mdctl &= ~0x0000001F;

    /* Do a Force Sync reset 
     *  Bit 31  : 1 => Force Bit 
     *  Bit 4-0 : 1 => Sync reset */
    uint32_t state=0x80000001;
    mdctl |=state;
    HW_WR_REG32(mdctrl_addr,mdctl);

    /* Trigger reset */
    HW_WR_REG32(0x400120,0x2);
    
    /* Wait until the operation is complete */
    while ((HW_RD_REG32(0x400128) & 0x2) != 0) {
        ;
    }

    uint32_t moduleId = TISCI_DEV_A53SS0;

    status = Sciclient_pmSetModuleState(moduleId,
                                        TISCI_MSG_VALUE_DEVICE_SW_STATE_AUTO_OFF,
                                        TISCI_MSG_FLAG_AOP,
                                        SystemP_WAIT_FOREVER);
    if(status != SystemP_SUCCESS)
    {
        DebugP_logError("CPU power off failed for device %d\r\n", moduleId);
    }
    else {
        DebugP_log("CPU powered off successfully for device %d\r\n", moduleId);
    }

Swargam, thank you for this example!  I will try it as you suggested and respond with results.   It will be a few days before I can try this myself.  I see that the module you are disabling is the main module rather than each individual core.  Am I correct in understanding that disabling a parent LPSC will also automatically disable all child LPSCs?

Thanks,

Joe

Hello Joe,

Yes, your understanding is correct . In the above example, I am trying to disable the entire cluster.

Which disables the power to all A53 cores.

Regards,

Anil.

Hi Swargam,

I have tried with the SCIclient alone and the added register writes.  In both cases, the debug output indicates that device 137 was successfully powered off.  However, I see no visible change in power consumption compared to this code being commented out.  What is the appropriate way to query the LPSC?

I've used this call before and after the code you provided:

status = SOC_getPSCState(SOC_PSC_DOMAIN_ID_MAIN, CSL_MAIN_PD_A53_CLUSTER_0, CSL_MAIN_LPSC_A53_CLUSTER_0, &pscDomainState, &pscModuleStateMain2MCU);

What I see is that status = 0, domain=1, module=3 before executing your code.  It remains the same after executing your code.

Is that the correct API call to determine if the A53's LPSC is really off?

Thanks,

Joe

Hello Joe,

Sorry for the above code.

The above code works for the AM62X device and I thought the LPSC module ID was the same for both devices.

I have checked at my side with the code below which works fine.

With the code below, I was able to power off the entire A53 cluster. After that, I verified the LPSC registers and SCI get call information.

Please try the test code below and see if this works or not.

Send the module stated as 0 for turning OFF the A53 core.

Regards,

Anil.

void Test_code(uint8_t module_state)
{


   /* PSC0 MDCTL register for A53_0 (0x400A00 + 4 * 20)*/
   uint32_t mdctrl_addr=0x400A50;
   uint32_t mdctl;//=HW_RD_REG32(mdctrl_addr);

   int32_t status;

   uint32_t moduleState = TISCI_MSG_VALUE_DEVICE_HW_STATE_OFF;
   uint32_t resetState = 0U;
   uint32_t contextLossState = 0U;


   status = Sciclient_pmGetModuleState(TISCI_DEV_A53SS0,
                              &moduleState,
                              &resetState,
                              &contextLossState,
                              SystemP_WAIT_FOREVER);

   if(status != SystemP_SUCCESS)
   {
       DebugP_logError("CPU Module state %d\r\n", moduleState);
   }
   else {
       DebugP_log("CPU Module state %d\r\n", moduleState);
   }



   /* Reset the Module Next Field (4-0) */
   //mdctl &= ~0x0000001F;

   /* Do a Force Sync reset
    *  Bit 31  : 1 => Force Bit
    *  Bit 4-0 : 1 => Module State   : 0 - > OFF : 1 - > device disable and keep in retention : ON 2 - > ON */


   mdctl = ( (1<<8U) | (1<<31U) | (module_state & 0x1F) );
   HW_WR_REG32(mdctrl_addr,mdctl);

   /*Power domain go transition   */
   HW_WR_REG32(0x400120,0x2);

   /* Wait until the power domain operation is complete */
   while ((HW_RD_REG32(0x400128) & 0x2) != 0) {
       ;
   }



   status = Sciclient_pmGetModuleState(TISCI_DEV_A53SS0,
                              &moduleState,
                              &resetState,
                              &contextLossState,
                              SystemP_WAIT_FOREVER);

   if(status != SystemP_SUCCESS)
   {
       DebugP_logError("CPU Module state %d\r\n", moduleState);
   }
   else {
       DebugP_log("CPU Module state %d\r\n", moduleState);
   }



  /* status = Sciclient_pmSetModuleState(TISCI_DEV_A53SS0,
                                       TISCI_MSG_VALUE_DEVICE_SW_STATE_ON,
                                       TISCI_MSG_FLAG_AOP,
                                       SystemP_WAIT_FOREVER);



   status = Sciclient_pmGetModuleState(TISCI_DEV_A53SS0,
                              &moduleState,
                              &resetState,
                              &contextLossState,
                              SystemP_WAIT_FOREVER);

   if(status != SystemP_SUCCESS)
   {
       DebugP_logError("CPU Module state %d\r\n", moduleState);
   }
   else {
       DebugP_log("CPU Module state %d\r\n", moduleState);
   }*/

}

Hi Anil,

I have tried the new code and the moduleState returns 0 now.  Surprisingly, I see no change to slightly higher power consumption when the A53 cluster is disabled.  Is that what you are seeing as well?

Thank you,

Joe

Hello Joe, 

I did not monitor the current consumption and just verified the Software side as the A53 cluster is disabled or not with the above code .

If anything is running on A53 core and other cores takes the current reading and, next, disable the A53 core Power OFF and take the current reading.

Then, the current reading is less when we disable the A53 core case ..

Regards,

Anil.

Hi Anil, in our case the bootloader is not loading any binary for the A53.  We are only launching the R5 cluster.  The current measurement is occurring on the DC supply powering the board.  That is where I see no difference in the cluster being enabled or disabled.

Do you know if the LPSCs in the AM64 family truly cut power to the A53 cluster? 

Thank you,

Joe

Joe Paolino said:

Hi Anil, in our case the bootloader is not loading any binary for the A53.  We are only launching the R5 cluster.  The current measurement is occurring on the DC supply powering the board.  That is where I see no difference in the cluster being enabled or disabled.

Hello Joe,

In my view, the above behavior is OK since SBL is not loading any app images of A53, then A53 Cores are not initialized by the SBL.

If you measure the current with the above case , the current only belongs to R5F cores and M4F cores only and not with the A53 core .

You can try this method ,: initialize the SOC with the SBL null which initializes all the cores.

Then take the current reading and next disable the Power off for A53 core with the above code in R5F core and take the current reading.

If you have done this method already, then I can assign thread to  Hw expert to support further. Please let me know.

The above code truly power off the A53 core and many customers are using the same method.

Regards,

Anil.

Anil,

Thank you for this suggestion.  I will give it a try and report back.

Joe

Hello Joe,

Ya sure ..I will wait for your reply .

Regards,

Anil.

Hi Anil, I have tried with the null bootloader and have confirmed the A53 consumption doesn't change in either module state.  I have been able to improve it's power consumption by calling SOC_moduleSetClockFrequency and setting it to 25MHz.  You mentioned above that the user doesn't have direct access to the PLL through the API. 

Is the above SOC_ function the correct way to attempt to change clocks throughout the device?

Will CTT SysConfig be enabled to modify these settings any time this year?

Thanks

Joe

Hello Joe,

I assume that there is no load on A53 core and just running A53 core and might be a chance  taking less current.

I am not sure how much current is taking when A53 core the run runs. If it is uA, then this testing will be very tough.

Yes, instead of changing clock frequency in the application, you can update change clock in SBL and follow the steps below .

Please see the array below. Here we need to update the-defaultClockHz variable to user-defined frequency and compile the SBL.

So, that your core will be operated at a user-defined frequency and an updated SBL app image should be flashed rather than the pre build SBL app image.

I routed your query to a low power modes expert and see he can help here.

Regards,

Anil.

Hi Joe,

Can you explain how you are measuring power?

From experimenting with AM62x, powering down one A53 core typically saves ~9mW of core power depending on the VDD_CORE supply to the ARM Cores. Since the core is still connected, there will be some current consumed even when a core is powered down.

Can you check the value in the PSC0_PDSTAT registers at these register addresses?:

• 0x00400200 (Power Domain 0 for General Purpose)
• 0x00400204 (Power Domain 1 for the ARM Cluster)
• 0x00400208 (Power Domain 2 for the A53 Core 0)
• 0x0040020C (Power Domain 3 for the A53 Core 1)

I want to understand if the status of the power domains just to make sure its in the expected state. The last 5 bits of the register are the PD's state.

I don't have RTOS expertise so I'm not sure how to execute this. If you need additional help with reading the registers, I'll re-assign to Anil to provide guidance.

Thanks,

Anshu

Hi Anshu,

I'm measuring power with a USB PD power analyzer connected inline with the USB port. 

These are the register values after executing the code provided by Anil.

Thank you,

Joe

Hi Joe,

Thanks for the information. 

I'm assuming the USB power analyzer is connected to the power supply of the board. Just so you're aware, that would measure the power of the whole board not just the AM243x SoC.

From the registers output, it looks like the Power Domains for A53 cores are still online as indicated by the 1 in the last hex digit. 

Is the RTI LPSC for the powered down A53 core disabled?

Thanks,

Anshu

Hi Anshu, using SOC_getPSCState for the LPSC above, I see that the domain state is 1 and the module state for

LPSC 22 is 3

LPSC 23 is 0.  ( I only have a single core device). 

The module state of the A53 cluster PD_A53_Cluster_0 is 0.  I believe the intent of Anil's code above was to disable the cluster.

Hi Joe,

Thanks for the information. I'll need to look into this further. Please ping this thread if you haven not received a response by Monday.

Thanks,

Anshu

Hi Anshu, pinging this thread as requested.

Joe

Hi Joe,

Thank you for the reminder. I was out sick for sometime.

To my understanding, LPSC_a53_0 is a dependency of LPSC_a53_cluster_0. From your previous post, you said the cluster is off which would have turned off it dependencies including the A53 core, but LPSC_a53_0 is on (status  = 3).

I'm wondering if one of the dependencies is preventing a power down of the Cluster itself.

Is it possible get the status of all of these LPSCs?

I was also looking into more A53 power consumption itself, but it seems does consume too much power, maybe around 10mW. If you are using a USB current monitor thats plugged into the power supply, I don't think you'll see a significant difference. Reminder that this would measure the whole board, not just the SoC.

Best Regards,

Anshu

Hi Anshu,

Initial PSC state after starting application debug (post NULL bootloader)

• 20: 3 (Power Domain:1)
• 21: 0 (Power Domain:1)
• 22: 3 (Power Domain:1)
• 23: 0 (Power Domain:1)

After calling Sciclient_pmSetModuleState for CORE_0, CORE_1, COMPUTE_CLUSTER with a value of TISCI_MSG_VALUE_DEVICE_SW_STATE_AUTO_OFF

and then executing Anil's code to shut down the subsystem:

• 20: 0 (Power Domain:1)
• 21: 0 (Power Domain:1)
• 22: 0 (Power Domain:0)
• 23: 0 (Power Domain:0)

Unfortunately, there is no detectable change in power to the nearest hundredth of a mW as I stepped through this code.

It should be noted that this was making use of NULL bootloader. 

When I upgraded OSPI bootloader to use SDK 10.0 and ran my application without any of the above PSC changes I can see the power drops by over 100mW.

Hello Joe,

When you use the NULL bootloader, the SBL will initializes all the cores without any app images.

If you use the SBL OPSI, then SBL will init the cores based on the multicore app images.

For example, the multicore app image had different images like all core R5F, M4F core and not the A53 core app image.

In this case, the SBL will initialize only the R5F core and M4F cores and not the A53 core.

Then, the usage of POWER is more in SBL NULL as compared to SBL OSPI .

If you send all the app images to the SBL OSPI, then SBL OSPI will initialize all the cores, then the current consumption is the same in both boot modes.

Regards,

Anil.

Hi Anil, I understand what you are saying about NULL.  What I observed through this process is that I have only been able to reduce power noticeably two ways:

• Using previous SDKs and setting A53 clock frequency to 25MHz in bootloader_soc.c
• Using the current SDK(10.0.0.2) and making no other changes to the default driver configurations.

Whether using SBL NULL or SBL OSPI, I see some measurable (~100mW) improvement using the above two approaches.  Setting the A53 LPSCs with the SCIclient shows equal to worse power consumption.

This takes me back to my original query at the top.  Does the AM64 offer no more means to reduce power in any substantial way?

Thank you,

Joe

Hi Anshu and Anil, thanks very much.  I have also tried 9.2.1.5.  I'll close out this thread.