ADC and DAC not working after resume from standby

[Emma]

We are migrating from ecosystem version 2.1.0 to 4.0.0. We have a custom board with STM32MP157C.

After resuming from STANDBY the ADCs and DAC, used by M4, no longer work. They are initialized and started without error, but all ADC channel data reads 2048. For the DAC, the DOR1 register reflects the data written to it, but there is no output on the DAC_OUT1 pin.

Additional information:

• The ADCs and DAC are used with DMA.
• The ADCs and DAC work fine after cold boot.
• On ecosystem version 2 the ADCs and DAC work both after cold boot and after resume from standby.
• We use trusted boot.

[Olivier GALLIEN]

Hi @Emma​ 

How did you manage DT update to switch from DV2.1 to DV4.0 ?

Did you use CubeMX 6.6 to generate a DV4.0 compliant backbone then re-integrate your customization ?

This is key to avoid any discrepancies between 2 versions which may have weird consequences.

"We use trusted boot." : I understand you configure the TF-A to use BL32 SP_MIN compare to OPTEE which is now the default and recommended solution, right ?

It's also interesting to see that in the past you already have issue around ADC and DMA

https://community.st.com/s/question/0D53W00000AZ6YGSA1/using-adc-with-dma-on-m4-causes-dma-transfer-error

Maybe worth to cross-checked you properly translate the correct settings into DV4.0 ?

If still stuck we may need further information as how M4 is started ( uboot/ Linux ) and any possible debug logs you may have during STANDBY / Wake-up and following ADC/DAC usage.

Olivier

[Emma]

Hi Olivier,

Thank you for your quick reply!

Yes, I used CubeMX v.6.6.1 to generate new device trees, then merged them with our changes for v2.

I use SP_MIN because the OPTEE configuration didn't boot and I haven't had time to troubleshoot it.

I have checked the etzpc configuration to ensure that the previous issue with peripheral DMA has not returned, and the configuration is correct (all required peripherals in MCU isolation). It is not the same symptoms this time anyway (the previous issue caused DMA transfer errors, and was unrelated to standby mode).

For debug logs of ADC/DAC usage, what information would be useful? ADC/DAC registers? Some RCC registers maybe?

[Emma]

So I've tried the OPTEE boot chain now and get the same problem. I did find though that the ADC and DAC issues are caused by the vdda regulator being disabled after standby. I didn't catch this at first because the Linux regulator framework reports it as enabled.

It's actually OPTEE that disables the regulator on resume from standby.

This is my device tree configuration for vdda (same for OPTEE and TF-A):

vdda:ldo5{
        regulator-name = "vdda";
        regulator-min-microvolt = <3300000>;
        regulator-max-microvolt = <3300000>;
        regulator-boot-on;
 
        standby-ddr-sr{
                regulator-off-in-suspend;
        };
 
        standby-ddr-off{
                regulator-off-in-suspend;
        };
};

[Emma · Accepted solution]

Replacing regulator-boot-on with regulator-always-on for vdda in the OPTEE device tree solves this problem.