Skip to content
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

ADC1 doesn't read correctly on STM32F7 #29309

Closed
disposedtrolley opened this issue Oct 18, 2020 · 7 comments
Closed

ADC1 doesn't read correctly on STM32F7 #29309

disposedtrolley opened this issue Oct 18, 2020 · 7 comments
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug

Comments

@disposedtrolley
Copy link

Describe the bug
The ADC_1 peripheral doesn't seem to work correctly on the STM32F7 series. I've tried compiling a test project following the test code supplied in the PR which introduced ADC support for STM32, but I get garbage readings on my Nucleo F767ZI board. The same code works fine on my Nucleo F401RE.

My settings:

  • F767ZI
    • ADC_1
    • Channel 12
  • F401RE
    • ADC_1
    • Channel 0

To Reproduce
Steps to reproduce the behavior:

  1. Build a minimal project according to the test code targeting the Nucleo F676ZI board. Use the following channel config:
static const struct adc_channel_cfg adc_cfg = {
    .gain = ADC_GAIN_1,
    .reference = ADC_REF_INTERNAL,
    .channel_id = 12
};
  • If gain and reference aren't provided when building for the F7, it results in errors when executing adc_channel_setup().
  1. Connect something to Pin 7 of CN10 (PB1).
  2. Observe that garbage readings are printed to the console.

Expected behavior
The ADC should output similar readings on the F7 series as the F4.

Impact
It was painful to debug whether this was an issue with my code, a hardware problem, or a Zephyr issue. Since the ADC implementation was only tested on some F4 boards, perhaps compatibility with other STM32 series should be removed from the docs.

Logs and console output
If applicable, add console logs or other types of debug information
e.g Wireshark capture or Logic analyzer capture (upload in zip archive).
copy-and-paste text and put a code fence (```) before and after, to help
explain the issue. (if unable to obtain text log, add a screenshot)

Environment (please complete the following information):

  • OS: MacOS
  • Toolchain: arm-none-eabi-gcc
  • Commit SHA or Version used

Additional context
Add any other context about the problem here.

@disposedtrolley disposedtrolley added the bug The issue is a bug, or the PR is fixing a bug label Oct 18, 2020
@disposedtrolley
Copy link
Author

disposedtrolley commented Oct 18, 2020

Okay I think I know what the issue is; the pinmux definitions for the STM32 Nucleo boards only map PA0 to ADC1. None of the other pins that are supported by the ADCs are mapped.

If I connect an analog device to PA0 of my Nucleo F767ZI board and use channel 0, I get correct ADC readings.

I'll see if I can open up a PR soon to fix this, at least for the F767ZI!

@disposedtrolley
Copy link
Author

Nevermind! I don't think any changes are required -- I just needed to create a devicetree overlay file and override the &adc1 definition so it includes the GPIO pins I'm using, i.e.

&adc1 {
	pinctrl-0 = <&adc1_in0_pa0 &adc1_in9_pb1>;
	status = "okay";
};

which adds &adc1_in9_pb1 so I can connect something to PB1 and read from channel 9 of ADC1.

@erwango erwango self-assigned this Oct 19, 2020
@erwango erwango added platform: STM32 ST Micro STM32 priority: low Low impact/importance bug labels Oct 19, 2020
@erwango
Copy link
Member

erwango commented Oct 19, 2020

@disposedtrolley As I understand, everything work fine then ?

@disposedtrolley
Copy link
Author

Yep all good @erwango

Do you think it's worthwhile to document the pinmuxing somewhere? Would there be a suitable section in the docs to cover this?

@erwango
Copy link
Member

erwango commented Oct 22, 2020

Do you think it's worthwhile to document the pinmuxing somewhere? Would there be a suitable section in the docs to cover this?

@disposedtrolley This is indeed required. My view is that it should belong to upcoming DT bindings doc section: #29374

@disposedtrolley
Copy link
Author

This is indeed required. My view is that it should belong to upcoming DT bindings doc section: #29374

@erwango Fantastic. I'll keep an eye out for the PR to be merged and see how the pinmux definitions look. I'll try adding documentation as necessary.

@erwango
Copy link
Member

erwango commented Oct 22, 2020

@disposedtrolley Txs for feedback. Feel free to close this point if we're done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

2 participants