ADC reading problems in subsequent firmware restarts on M4 of STM32MP157AAA

[AgaGioUmpiSrl]

On a proprietary board based on STM32MP157AAA, code was created on the M4 core for reading 11 analog gates managed in DMA (end of sequence interrupt) of ADC1 and ADC2 in independent mode with conversion start via software executed cyclically. The adc values obtained are then passed to the control loop through the command port implemented on /dev/ttyRPMSG0 to the A7NS core where an application runs. Furthermore, a second virtual port (/dev/ttyRPMSG1) was used to trace the execution of the code on M4. The Start/Stop of the M4 firmware occurs via a script that uses remoteproc linux A7 "Non Secured".

Mcu Reference : STM32MP157AAAx
Firmware Package : STMCube FW_MP1 V1.5.0
Manifest Version : openstlinux-5.10-dunfell-mp1-21-11-17
Manifest Content : TF-A 2.4, Linux 5.10.61, U-Boot 2020.10

TF-A Setting ...

&etzpc{
secure-status = "okay";
st,decprot = <
/*"NS_R S_W" peripherals*/
DECPROT(STM32MP1_ETZPC_DDRCTRL_ID, DECPROT_NS_R_S_W, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_DDRPHYC_ID, DECPROT_NS_R_S_W, DECPROT_LOCK)
/*"Non Secured" peripherals*/
DECPROT(STM32MP1_ETZPC_DMA1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_DMAMUX_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_ETH_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_TT_FDCAN_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_HASH1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_I2C4_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_I2C6_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_RNG1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_SPI5_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_TIM4_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_UART4_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_UART8_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_USART1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_USART3_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_OTG_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
/*"Secured" peripherals*/
DECPROT(STM32MP1_ETZPC_STGENC_ID, DECPROT_S_RW, DECPROT_UNLOCK)
/*"Mcu Isolation" peripherals*/
DECPROT(STM32MP1_ETZPC_ADC_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_DMA2_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_I2C1_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_I2C2_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_TIM6_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
DECPROT(STM32MP1_ETZPC_TIM7_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
};

Description of the problem encountered:
When the board is first turned on and the firmware on the M4 is started the readings of the 11 inputs are correct and consistently follow the changes to the inputs. After a subsequent Stop and Restart of the M4 firmware, one of the inputs on ADC1 (IN16 Rank 6 PA0) also appears influenced by the value present on another ADC1 input (IN0 Rank 4 ANA0). That is, both values present in PA0 and ANA0 contribute proportionally to the adc value read of the PA0 input, while all the other inputs (including ANA0) work correctly.
The only way to restore the correct readings is to reboot!

Assuming a failure or incomplete initialization of the peripherals in charge of the M4 core by the FW_MP1 V1.5.0 libraries, I tried to perform a reset from A7 NS of all the peripherals but without obtaining different results.

Reset script ...

#!/bin/bash

echo Reset DMAMUX, DMA2, ADC12
devmem2 0x50000998 w 0x00000026
devmem2 0x5000099C w 0x00000026

echo Reset TIM6, TIM7, I2C1, I2C2
devmem2 0x50000980 w 0x00600030
devmem2 0x50000984 w 0x00600030

Result of running the reset script ...

Reset DMAMUX, DMA2, ADC12
/dev/mem opened.
Memory mapped at address 0xb6fa5000.
Read at address 0x50000998 (0xb6fa5998): 0x00000000
Write at address 0x50000998 (0xb6fa5998): 0x00000026, readback 0x00000026
/dev/mem opened.
Memory mapped at address 0xb6f0e000.
Read at address 0x5000099C (0xb6f0e99c): 0x00000026
Write at address 0x5000099C (0xb6f0e99c): 0x00000026, readback 0x00000026
Reset TIM6, TIM7, I2C1, I2C2
/dev/mem opened.
Memory mapped at address 0xb6f28000.
Read at address 0x50000980 (0xb6f28980): 0x00000000
Write at address 0x50000980 (0xb6f28980): 0x00600030, readback 0x00600030
/dev/mem opened.
Memory mapped at address 0xb6f5a000.
Read at address 0x50000984 (0xb6f5a984): 0x00600030
Write at address 0x50000984 (0xb6f5a984): 0x00600030, readback 0x00600030

Has anyone encountered a similar problem? How did he solve it?

[PatrickF]

HI @AgaGioUmpiSrl 

maybe similar issue that this post

https://community.st.com/t5/stm32-mpus-products/troubleshoot-with-cortex-m4-reinitialization-on-stm32mp1/m-p/52038

Default Cortex-M4 generated FW by CubeMx and more generally HAL initialization are somewhat assuming the peripherals are in reset state while it is not the case when you restart the Cortex-M4.

Regards.

[AgaGioUmpiSrl]

Hi @PatrickF 

thank you for your quick response.

I tried to perform a reset cycle of all the peripherals involved in the firmware on the M4 by doing it with memdev2 from the A7, but without obtaining the desired results. Actually logging the contents of the ADC and DMA registers, after this reset intervention, they appear with the default values after the reset. But the problem of wrong values on the analog input in question remains.

Before starting the firmware I run the following bash script...

#!/bin/bash

echo Reset DMAMUX, DMA2, ADC12
devmem2 0x50000998 w 0x00000026
devmem2 0x5000099C w 0x00000026

echo Reset TIM6, TIM7, I2C1, I2C2
devmem2 0x50000980 w 0x00600030
devmem2 0x50000984 w 0x00600030

 Which correspond to the calls
__HAL_RCC_***_FORCE_RESET();
__HAL_RCC_***_RELEASE_RESET();
on all peripherals managed by M4.

Or do you think that if run by M4 it has a different behavior from what I have already tested?

[PatrickF · Accepted solution]

Have you ensure you did not touch the SYSCFG_PMCSETR bits 24 and 25 ?

Regards

[AgaGioUmpiSrl]

Hi @PatrickF,

the problem of the interference of the readings was due to an incorrect initialization of SYSCFG_PMCSETR as you highlighted, thank you for the assistance provided.

CubeMx had correctly composed the right initialization of this register which predicts the open state of these switches

HAL_SYSCFG_AnalogSwitchConfig(SYSCFG_SWITCH_PA0, SYSCFG_SWITCH_PA0_OPEN);
HAL_SYSCFG_AnalogSwitchConfig(SYSCFG_SWITCH_PA1, SYSCFG_SWITCH_PA1_OPEN);
...
void HAL_SYSCFG_AnalogSwitchConfig(uint32_t SYSCFG_AnalogSwitch , uint32_t SYSCFG_SwitchState )
{
  /* Check the parameter */
  assert_param(IS_SYSCFG_ANALOG_SWITCH(SYSCFG_AnalogSwitch));
  assert_param(IS_SYSCFG_SWITCH_STATE(SYSCFG_SwitchState));
  SYSCFG->PMCCLRR = SYSCFG_AnalogSwitch;
  SYSCFG->PMCSETR = (uint32_t)(SYSCFG_SwitchState);
}

But the problem arises from an inversion of the definitions of SYSCFG_SWITCH_PAx_OPEN and SYSCFG_SWITCH_PAx_CLOSE present in STM32MP1xx_HAL_Driver/Inc/stm32mp1xx_hal.h

#define SYSCFG_PMCSETR_ANA0_SEL_Pos (24U)
#define SYSCFG_PMCSETR_ANA0_SEL_Msk (0x1UL << SYSCFG_PMCSETR_ANA0_SEL_Pos)
#define SYSCFG_PMCSETR_ANA0_SEL_SEL SYSCFG_PMCSETR_ANA0_SEL_Msk
#define SYSCFG_PMCSETR_ANA1_SEL_Pos (25U)
#define SYSCFG_PMCSETR_ANA1_SEL_Msk (0x1UL << SYSCFG_PMCSETR_ANA1_SEL_Pos)
#define SYSCFG_PMCSETR_ANA1_SEL_SEL SYSCFG_PMCSETR_ANA1_SEL_Msk
...
#define SYSCFG_SWITCH_PA0 SYSCFG_PMCSETR_ANA0_SEL_SEL  /*!< Select PA0 analog switch */
#define SYSCFG_SWITCH_PA1 SYSCFG_PMCSETR_ANA1_SEL_SEL  /*!< Select PA1 analog switch */
...
#define SYSCFG_SWITCH_PA0_OPEN SYSCFG_PMCSETR_ANA0_SEL_SEL /*!< PA0 switch opened */
#define SYSCFG_SWITCH_PA0_CLOSE (uint32_t)0x00000000) /*!< PA0 switch closed */
#define SYSCFG_SWITCH_PA1_OPEN SYSCFG_PMCSETR_ANA1_SEL_SEL /*!< PA1 switch opened */
#define SYSCFG_SWITCH_PA1_CLOSE ((uint32_t)0x00000000) /*!< PA1 switch closed*/

By switching the opening of these switches again after the incorrect configuration, the problem was solved! Analog readings are correct even following consecutive Stop/Starts of the M4 firmware.

I am satisfied with the resolution to my problem, although I cannot explain the behavior of the correct readings at the first start of the M4 firmware before applying the fix.

Thanks