8ULP TPM3 unexpected behavior when switching power modes

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

8ULP TPM3 unexpected behavior when switching power modes

1,115 Views
MaxSaka
Contributor II

Hello,

I have been exploring the "evkmimx8ulp_power_mode_switch" example which has been customized to support the MaaXBoard 8ulp hardware (https://www.avnet.com/wps/portal/us/products/avnet-boards/avnet-board-families/maaxboard/maaxboard-8...)

On this hardware, TPM3 is used to drive the backlight of the MIPI display and does operate properly, the A35 core can successfully set the backlight intensity and TPM3 will shut off when the A35 core is placed in suspend mode.

Issues arise while exercising the various power modes through the M33 application and the A35 core is suspended, for example, If the M33 core is placed into Deep Sleep mode through the examples console, the backlight activates (TPM3 turns on) however, when exercising Sleep Mode the backlight remains off. It is my expectation that TPM3 should remain off while the A35 core is suspended regardless of the power mode.

Can you please help us identify the potential causes for this behavior, why would TPM3 behave differently when the M33 is in Deep Sleep mode vs Sleep mode.

Running imx-6.1.22-2.0.0 on silicon version A2
The source code I'm working with is located here
https://github.com/MaximSaka/maaxboard8ulp_power_mode_switch

Thank you in advance for any insight you may be able to provide.

Best Regards.

 

 

 

Tags (1)
0 Kudos
Reply
12 Replies

1,003 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello,

Unfortunately I couldn't find anything else aside from the information I have already shared with you,
I have contacted internal team regarding this, I will update here as soon as I get more information.

Thank you for your patience,
Best regards/Saludos,
Aldo.

0 Kudos
Reply

1,000 Views
MaxSaka
Contributor II

Hi Aldo,
Thank you for your assistance.

Regards

0 Kudos
Reply

996 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello,

I had an small Idea Could you share which is the mux you have used for TPM3 on your design for backlight?

This because some of the mux options for TPM3 are used as wakeup source:
https://github.com/MaximSaka/maaxboard8ulp_power_mode_switch/blob/main/power_mode_switch.c#L277

Best regards,
Aldo.

0 Kudos
Reply

978 Views
MaxSaka
Contributor II

Hi Aldo,

The IOMUX using PTB13 as TPM3_CH5 on MaaXBoard-8ULP.

Best regards.

0 Kudos
Reply

971 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello,

Thank you for sharing, please try adding this pin to the skiped ones so it is not overwritten:
https://github.com/MaximSaka/maaxboard8ulp_power_mode_switch/blob/main/power_mode_switch.c#L388

Best regards/Saludos,
Aldo.

0 Kudos
Reply

946 Views
MaxSaka
Contributor II

Hi Aldo,

I made the change you recommended however, that did not make a difference.

While testing further I did observe that the backlight remains off while in deep sleep mode and turns on once the M core resumes. Subsequently, if the A core is resumed it no longer is able to control the backlight and a reboot is required to restore the backlight control.

It seems to me that the issue is somehow related to the M core resuming after deep sleep mode.

Best regards.

0 Kudos
Reply

831 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello!

Sorry for the delayed response, it is really difficult to really find whats going on at this point, I believe that there may be something in the code that it is causing the M-Core to take domain over the pad/peripheral. If possible have you tried to reproduce a similar scenario on an NXP EVK?

Just to make sure at which poin it is causing the issue, could you try setting the M-Core and A-core into deep sleep and only waking-up the A-core?

Also, please try to skip the disabling of PTB block in this section of the code:
https://github.com/MaximSaka/maaxboard8ulp_power_mode_switch/blob/main/power_mode_switch.c#L385

Similar to what it is doing here:
https://github.com/MaximSaka/maaxboard8ulp_power_mode_switch/blob/main/power_mode_switch.c#L385

Best regards/Saludos,
Aldo.

0 Kudos
Reply

796 Views
MaxSaka
Contributor II

Hi Aldo,

Thank you for your continued support, I will try your suggestion and provide feedback.
The EVK that I have is an older version with A0 silicon, do you think that matters in this case? If not, I can try to reproduce the issue on the EVK.

Best regards

0 Kudos
Reply

783 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello,

I don't think that this will be an issue for the test (A0 vs A1), so please give it a try. Please do let me know of the results.

Best regards/Salduos,
Aldo.

0 Kudos
Reply

1,017 Views
MaxSaka
Contributor II

Hi Aldo,

Were you able to look into this any further?

Please let me know.
Best Regards.

0 Kudos
Reply

1,073 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello,

I'll need to keep looking more deep into this, since as per RM TPM3 is part of the DSP domain, when M33 goes into deep sleep PCC2 module is Clock gated, when it goes to sleep PCC2 module remains active, this is the only thing that I could see that is "different" between this 2 power modes that could cause some kind of unexpected behavior.

This may be a good starting point, Fusion DSP can operate is Deep Sleep mode if FRO clock is available. Could you try enabling FRO clock in the Deep sleep routine of the M33?

I did not go full into all your code, but I believe you have everything covered for sharing TPM3 between M33 and A35, right?

Best regards/Saludos,
Aldo.

0 Kudos
Reply

1,062 Views
MaxSaka
Contributor II

Hi Aldo,

Thank you for your response.

It appears that the switch to FRO is already accounted for in function LPM_SystemDeepSleep(). which will execute the following lines:

    /*
     * Switch clock source from PLL0/1 to FRO to save more power during Power Down,
     * then switch back after wakeup in function BOARD_ResumeClockInit()
     */
    BOARD_SwitchToFROClk(BOARD_GetRtdDriveMode());
    BOARD_DisablePlls();
 
I was wondering if I need to disable PWM or TPM3 in the APP_SRTM_Suspend() function. Currently this function is called however it is empty.
 
APP_SRTM_Suspend() is called at the end of APP_Suspend()
 
Thank you.
Regards. 

 

0 Kudos
Reply