STM32H7 ADCv4 patches Topic is solved

Report here problems in any of ChibiOS components. This forum is NOT for support.
User avatar
Giovanni
Site Admin
Posts: 13577
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 876 times
Been thanked: 750 times
Contact:

Re: STM32H7 ADCv4 patches

Postby Giovanni » Fri Apr 23, 2021 8:30 am

Hi,

I fixed the issue in all STM32 drivers and in the template, not tested it yet but should be fine. It had no impact on HLD because the type is defined in the LLD.

Now ADCv1...ADCv5 all have the same errors handling code, things diverged a bit with time.

Giovanni

User avatar
alex31
Posts: 338
Joined: Fri May 25, 2012 10:23 am
Location: toulouse, france
Has thanked: 34 times
Been thanked: 50 times
Contact:

Re: STM32H7 ADCv4 patches

Postby alex31 » Mon Apr 26, 2021 6:17 pm

Hello,

I come back with ADCv4 patches, split in these parts :

° 1-adcv4_awd_fixes.patch
fixes several typos and misses with THR and AWD register copy.

° 2-adcv4_testhal_fixes.patch
fixes adc driver now check PWR_CR2_MONEN if VBAT or/and TEMP sensor is initialized
fixes cfgr need ADC_CFGR_CONT_ENABLED if DEPTH > 1 and/or continous mode is used

° 3-dualmode_fixes.patch
fixes missing ADC12_CCR_DUAL bit setting

° 4-isrhook_fixes.patch
that part was in the patch that was proposed here :
https://forum.chibios.org/viewtopic.php?f=35&t=5525&sid=0a67776478b52a263564251b4a1f9ddd#p39438
don't know if it's still relevant, but did not want to clear it silently

° 5-sample-wide_proposal.patch
this is a proposal to enable more that 16 bits wide sample, when oversampling is activated.

Sorry for the work for reviewing all of that ...

Alexandre
Attachments
adcv4_patches_over_trunck_26_04_21.zip
several adcv4 patches to fix awd, dual_mode, testhal and wide_sample proposal
(5.68 KiB) Downloaded 13 times

User avatar
Giovanni
Site Admin
Posts: 13577
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 876 times
Been thanked: 750 times
Contact:

Re: STM32H7 ADCv4 patches

Postby Giovanni » Sat May 08, 2021 10:38 am

Hi,

Committed in trunk patches 1..4. I have a request for patch 5, I suggest making a single configuration with samples size (STM32_ADC_SAMLES_SIZE: 8, 16, 32) and perform all checks based on the value. In addition, everything should be ported to 20.3 too.

Could you take care of this when you have some time?

Giovanni

User avatar
alex31
Posts: 338
Joined: Fri May 25, 2012 10:23 am
Location: toulouse, france
Has thanked: 34 times
Been thanked: 50 times
Contact:

Re: STM32H7 ADCv4 patches

Postby alex31 » Wed May 12, 2021 11:45 am

Hello,

here is a proposal for unified ADC_SAMPLES_SIZE definition above actual trunk, and portage of the whole thing to 20.3.

I have tested with 8, 16, 32 bits in continuous and one shot mode without issue.

It is not possible to port the patch to 20.3 without using your new event_mask, so
ADCv4/hal_adc_lld.{h,c} are identical in 20.3 and trunk after both patches applied.

One thing to remember is the behavior of driver concerning CONT bit, some drivers take care of it, and some don't.
ADCv4 leave the CONT bit management to the user : it should be set in continuous mode, and in one_shot mode when DEPTH is > 1.

another approach could have been to let the driver manage CONT bit, only when DISCEN bit is not set in the provided cfgr value.

Alexandre
Attachments
unified_adcv4_sample_size_over_20.3.patch.zip
(4.35 KiB) Downloaded 10 times
unified_adcv4_sample_size_over_trunk.zip
(1.88 KiB) Downloaded 9 times

User avatar
Giovanni
Site Admin
Posts: 13577
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 876 times
Been thanked: 750 times
Contact:

Re: STM32H7 ADCv4 patches

Postby Giovanni » Tue May 25, 2021 10:22 am

Hi Alex,

I committed the patch on trunk then ported the whole trunk driver to 20.x, no point in keeping 2 versions around.

Could you give it a try?

Giovanni

User avatar
alex31
Posts: 338
Joined: Fri May 25, 2012 10:23 am
Location: toulouse, france
Has thanked: 34 times
Been thanked: 50 times
Contact:

Re: STM32H7 ADCv4 patches

Postby alex31 » Wed May 26, 2021 8:00 am

Hello,

tested 20.3 and trunk, and seems all correct for me !

Alexandre

mikeprotts
Posts: 157
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 19 times
Been thanked: 25 times

Re: STM32H7 ADCv4 patches

Postby mikeprotts » Wed May 26, 2021 3:46 pm

I've just been taking a look at this (using an STM32H743 old style). The documents suggest that the VREF and TS values have to be taken from ADC3, but the sample uses ADC1. Also the channels need to be changed to 19 (VREF) & 18 (TS), using SMPR2.

When I run the testhal/STM32/mutli/ADC sample as provided, it seems to run ok, but looks like the values collected are random, varying too much to be realistic VREF.

I changed the testhal sample to use ADC3 (portab.h) and correct channels (portab.c), but it halts in the error callback, with err = 1 (ADC_ERR_DMAFAILURE)

Code: Select all

(gdb) where
#0  0x0800335c in chSysHalt (reason=0x8006420 "it happened") at ../../../../os/rt/src/chsys.c:222
#1  0x080059ce in adcerrorcallback (adcp=0x24000038 <ADCD3>, err=1) at main.c:72
#2  0x08001734 in adc_lld_serve_bdma_interrupt (adcp=0x24000038 <ADCD3>, flags=8)
    at ../../../../os/hal/ports/STM32/LLD/ADCv4/hal_adc_lld.c:253
#3  0x08001f94 in Vector244 () at ../../../../os/hal/ports/STM32/LLD/BDMAv1/stm32_bdma.c:125
#4  <signal handler called>
#5  0x55555554 in ?? ()


Has anyone tried ADC3? Any suggestion as to how to diagnose the DMA failure?

I'm using the latest trunk, arm-none-eabi-gcc 7.3.1.

Cheers
Mike

User avatar
Giovanni
Site Admin
Posts: 13577
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 876 times
Been thanked: 750 times
Contact:

Re: STM32H7 ADCv4 patches

Postby Giovanni » Wed May 26, 2021 6:09 pm

Hi,

ADC3 uses BDMA, is the buffer placed in a RAM accessible by BDMA?

Giovanni

mikeprotts
Posts: 157
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 19 times
Been thanked: 25 times

Re: STM32H7 ADCv4 patches

Postby mikeprotts » Wed May 26, 2021 7:18 pm

That seems to be the problem - need to allocate to ram4. I need to check the values are correct as I seem to have a temperature of 3810.46'C, but VREF looks good at 3295 mV. I suspect my calculations are off as they are unchanged from the STM32F7 code.

What's the preferred option for portable allocation - I use gcc and:

Code: Select all

adcsample_t samples1[CACHE_SIZE_ALIGN(adcsample_t, ADC_GRP1_NUM_CHANNELS * ADC_GRP1_BUF_DEPTH)]
  __attribute__ ((section (".ram4")));


I should be able to generate a small patch for this demo, so I'd prefer to make it fit the usual pattern.

Thanks
Mike

User avatar
Giovanni
Site Admin
Posts: 13577
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 876 times
Been thanked: 750 times
Contact:

Re: STM32H7 ADCv4 patches

Postby Giovanni » Wed May 26, 2021 7:51 pm

It is best to include ccportab.h and use CC_SECTION() macro, it is compiler-independent, place it before the buffer declaration. The section to use would be .ram4_clear, you want the RAM to be initialized.

Giovanni


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 4 guests