stm32 adc driver_api test fails on stm32wb55 and stm32l5

[FRASTM]

Describe the bug tests/drivers/adc/adc_api test fails when running on

• nucleo_wb55rg
• stm32l562e_dk

Test execution blocking in the first sequence _test_adc_asynchronouscall

Please also mention any information which could help others to understand the problem you're facing:

• nucleo_wb55rg board or stm32l562e_dk disco kit
  • Looks like a regression after https://github.com/zephyrproject-rtos/zephyr/pull/49039

To Reproduce Steps to reproduce the behavior:

1. west build -p auto -b nucleo_wb55rg tests/drivers/adc/adc_api/3. make
2. west flash

Expected behavior

------ TESTSUITE SUMMARY START ------                                                

SUITE PASS - 100.00% [adc_basic]: pass = 5, fail = 0, skip = 1, total = 6 duration =s
 - PASS - [adc_basic.test_adc_asynchronous_call] duration = 0.007 seconds            
 - PASS - [adc_basic.test_adc_invalid_request] duration = 0.012 seconds              
 - PASS - [adc_basic.test_adc_repeated_samplings] duration = 0.098 seconds           
 - PASS - [adc_basic.test_adc_sample_one_channel] duration = 0.008 seconds           
 - SKIP - [adc_basic.test_adc_sample_two_channels] duration = 0.001 seconds          
 - PASS - [adc_basic.test_adc_sample_with_interval] duration = 0.410 seconds         

------ TESTSUITE SUMMARY END ------                                                  

===================================================================                  
PROJECT EXECUTION SUCCESSFUL   

Logs and console output

*** Booting Zephyr OS build zephyr-v3.1.0-4714-ge5b049249eab  ***                    
Running TESTSUITE adc_basic                                                          
===================================================================                  
START - test_adc_asynchronous_call

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows)
• Toolchain (e.g Zephyr SDK, ...)
• Commit SHA or Version used

Additional context Add any other context that could be relevant to your issue, such as pin setting, target configuration, ...

[FRASTM]

Could it be a mistmatch between channel and index in the adc_stm32_teardown_channels() function call : Suggested correction:

diff --git a/drivers/adc/adc_stm32.c b/drivers/adc/adc_stm32.c
index 2015601b2a..69541a392c 100644
--- a/drivers/adc/adc_stm32.c
+++ b/drivers/adc/adc_stm32.c
@@ -901,7 +901,7 @@ static int start_read(const struct device *dev,

    err = adc_context_wait_for_completion(&data->ctx);

-   adc_stm32_teardown_channels(dev, index);
+   adc_stm32_teardown_channels(dev, channel);

    return err;
 }

[ycsin]

Not sure what could be the cause yet, but currently the adc_stm32_teardown_channels is getting the same arg as the adc_stm32_setup_channels since two of them are similar

[FRASTM]

On both stm32wb55 and stm32L5x , the VREFINT channel is on the channel 0 of the ADC1/2 During the adc_stm32_teardown_channels() since the adc has config->has_vref_channel true, the __LL_ADC_CHANNEL_TO_DECIMAL_NB(LL_ADC_CHANNEL_VREFINT) gives 0 which corresponds to the ADC_1ST_CHANNEL_ID of the sequence.

One possible WA for that test execution is to remove the has-vref-channel property (with boards/overlay file)

&adc1 {
    /delete-property/ has-vref-channel;
};

Another, for this particular test purpose is to set ADC_1ST_CHANNEL_ID = 1 for stm32wb55 and stm32l5 platforms.

diff --git a/tests/drivers/adc/adc_api/src/test_adc.c b/tests/drivers/adc/adc_api/src/test_adc.c
index f1e05c5ab5..4c16691169 100644
--- a/tests/drivers/adc/adc_api/src/test_adc.c
+++ b/tests/drivers/adc/adc_api/src/test_adc.c
@@ -214,8 +214,12 @@
 #define ADC_GAIN       ADC_GAIN_1
 #define ADC_REFERENCE      ADC_REF_INTERNAL
 #define ADC_ACQUISITION_TIME   ADC_ACQ_TIME_DEFAULT
+#if defined(CONFIG_BOARD_NUCLEO_WB55RG) || defined(CONFIG_BOARD_STM32L562E_DK)
+/* channel 0 is for VREFINT internal channel */
+#define ADC_1ST_CHANNEL_ID 1
+#else
 #define ADC_1ST_CHANNEL_ID 0
+#endif /* CONFIG_BOARD_NUCLEO_WB55RG or CONFIG_BOARD_STM32L562E_DK */

 #elif defined(CONFIG_BOARD_NUCLEO_F302R8) || \
    defined(CONFIG_BOARD_NUCLEO_G474RE) || \
    defined(CONFIG_BOARD_NUCLEO_L412RB_P)

[FRASTM]

However, the adc_stm32_teardown_channels when the channel ID is 0 --> VREFINT is not enabling (adc_stm32_enable) correctly this channel because it waits endlessly for LL_ADC_IsActiveFlag_ADRDY