Skip to content

Fix AnalogIn implementation on STM32G4 series #13601

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Sep 30, 2020

Conversation

AGlass0fMilk
Copy link
Member

Summary of changes

This PR reintroduces AnalogIn on the STM32G4 series based targets (eg: NUCLEO_G474RE). It also introduces fixes to the AnalogIn HAL API implementation.

Fixes in this PR include:

  • Enabling the peripheral clocks for ADCs during initialization
  • Removing internal mappings from some channels that should be routed to external pin inputs.

@jeromecoutant Please review and possibly update this PR at your discretion... I am not as familiar with how to handle the internal ADC channels (ie: Temperature, VREF, OPAMP, etc). This PR removes all support for internal ADC channels as it stands right now. It seems ADC2 has more inputs than on the F3 series upon which this analog in implementation was based. I tried to use the pin A2 as an analog input on my NUCLEO G474 and the current analog in implementation routed it to an internal OP amp channel instead of the PA4/A2.

Impact of changes

Migration actions required

Documentation

None


Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

@jeromecoutant

@AGlass0fMilk
Copy link
Member Author

@jeromecoutant Should the Nucleo G474 be using USE_PLL_HSE_EXTC or USE_PLL_HSE_XTAL? The current default is USE_PLL_HSE_EXTC but I think the hardware is actually a crystal not an oscillator.

mbed-os/targets/targets.json

Lines 2441 to 2445 in 356effa

"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSE_EXTC",
"macro_name": "CLOCK_SOURCE"
},

@ciarmcom ciarmcom added the release-type: patch Indentifies a PR as containing just a patch label Sep 11, 2020
@ciarmcom ciarmcom requested review from jeromecoutant and a team September 11, 2020 17:30
@ciarmcom
Copy link
Member

@AGlass0fMilk, thank you for your changes.
@jeromecoutant @ARMmbed/mbed-os-maintainers please review.

@AGlass0fMilk
Copy link
Member Author

@jeromecoutant Also, since the clock speed on this target is so high by default I am seeing small offsets in my ADC readings due to the short accumulation time.

Setting the ADC prescaler to divide by 4 and setting the sampling time to 640.5 cycles greatly improves the offset but maybe there's a way to get make it so I'm not maxing out the settings?

0xc0170
0xc0170 previously approved these changes Sep 16, 2020
@0xc0170
Copy link
Contributor

0xc0170 commented Sep 16, 2020

@ARMmbed/team-st-mcd Please review

@mergify mergify bot added needs: CI and removed needs: review labels Sep 16, 2020
@0xc0170
Copy link
Contributor

0xc0170 commented Sep 17, 2020

CI started

@mbed-ci
Copy link

mbed-ci commented Sep 17, 2020

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-ARM ✔️
jenkins-ci/mbed-os-ci_build-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️
jenkins-ci/mbed-os-ci_dynamic-memory-usage ✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest ✔️

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 17, 2020

Set back to review, waiting for @jeromecoutant to review

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 21, 2020

@jeromecoutant Can you review? this can go in if approved.

Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi

I have tested ci-test-shield, results are OK :-)

But...

  • it seems there are too many TODO in comments?
  • it works but I couldn't see any __HAL_RCC_ADC12_CLK_ENABLE()) call for ex... Need to check...
  • internal channels to check

@@ -153,11 +163,15 @@ uint16_t adc_read(analogin_t *obj)

// Configure ADC channel
sConfig.Rank = ADC_REGULAR_RANK_1;
sConfig.SamplingTime = ADC_SAMPLETIME_24CYCLES_5;
sConfig.SamplingTime = ADC_SAMPLETIME_247CYCLES_5;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really need so much time ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my math is correct, with the PCLK @ 180MHz and the ADC prescaler set to DIV2, a sample time of 24.5 clock cycles is only ~272 nanoseconds... I think this is quite short for most of the slow signals Mbed users will be trying to read with the simple AnalogIn API.

My comment from before:

Also, since the clock speed on this target is so high by default I am seeing small offsets in my ADC readings due to the short accumulation time.
Setting the ADC prescaler to divide by 4 and setting the sampling time to 640.5 cycles greatly improves the offset but maybe there's a way to get make it so I'm not maxing out the settings?

Perhaps we could increase the ADC prescaler?

@AGlass0fMilk
Copy link
Member Author

Hi

I have tested ci-test-shield, results are OK :-)

But...

* it seems there are too many TODO in comments?

* it works but I couldn't see any __HAL_RCC_ADC12_CLK_ENABLE()) call for ex... Need to check...

* internal channels to check

The TODOs are mostly for future reference. I'm not sure where (or if) the ADC is deinitialized. We should deinitialize the clock at the same time to save power. Regardless I think this is an improvement over the current target support.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 21, 2020

Are TODO's required there? I would rather keep TODO as an issue rather than in the code.

@jeromecoutant
Copy link
Collaborator

Here is my branch: 885aca7

@jeromecoutant
Copy link
Collaborator

Note that analogin_free exists since #11032
And this has not been implemented for every targets...

@mergify mergify bot dismissed 0xc0170’s stale review September 21, 2020 16:20

Pull request has been modified.

@AGlass0fMilk
Copy link
Member Author

@jeromecoutant I implemented analogin_free. Let me know your thoughts. It's pretty rudimentary (enable counting) but I think it will work. I will look at your branch and merge the internal ADC channel changes.

@0xc0170 I removed the TODOs.

@AGlass0fMilk
Copy link
Member Author

@jeromecoutant I merged your internal ADC channel changes: bbc7355

Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe only 2 counters are needed ? adc12 and adc345 ?

@@ -158,6 +204,10 @@ uint16_t adc_read(analogin_t *obj)
sConfig.OffsetNumber = ADC_OFFSET_NONE;
sConfig.Offset = 0;

/**
* TODO - what about internal channels? VBAT, VREF, Temperature?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To remove in the next commit ?

@@ -163,7 +199,7 @@ uint16_t adc_read(analogin_t *obj)

// Configure ADC channel
sConfig.Rank = ADC_REGULAR_RANK_1;
sConfig.SamplingTime = ADC_SAMPLETIME_247CYCLES_5;
sConfig.SamplingTime = ADC_SAMPLETIME_24CYCLES_5;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you should keep 247 cycles value,
some tests are failing with 24 value...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I should increase the ADC clock prescaler?

@AGlass0fMilk
Copy link
Member Author

Maybe only 2 counters are needed ? adc12 and adc345 ?

That was my initial implementation but then I figured having a counter for each ADC would allow us to deinitialize each ADC individually as well.

@AGlass0fMilk
Copy link
Member Author

@jeromecoutant Please review

@mergify mergify bot added needs: CI and removed needs: review labels Sep 30, 2020
@0xc0170
Copy link
Contributor

0xc0170 commented Sep 30, 2020

CI started

@mbed-ci
Copy link

mbed-ci commented Sep 30, 2020

Jenkins CI Test : ✔️ SUCCESS

Build Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️
jenkins-ci/mbed-os-ci_dynamic-memory-usage ✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest ✔️

@0xc0170 0xc0170 merged commit fbe0409 into ARMmbed:master Sep 30, 2020
@mergify mergify bot removed the ready for merge label Sep 30, 2020
@mbedmain mbedmain added release-version: 6.4.0 Release-pending and removed release-type: patch Indentifies a PR as containing just a patch Release-pending labels Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants