Skip to content

Analog input reading for Feather M0 pins A1 and A2 always return max value 4095 #3

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

Closed
tdicola opened this issue Sep 26, 2016 · 0 comments

Comments

@tdicola
Copy link

tdicola commented Sep 26, 2016

Trying to read analog inputs A1 and A2 on a Feather M0 always returns the max value of 4095 regardless of the voltage on the pin. For example:

import machine
adc = machine.ADC(machine.Pin("A1"))
adc.read()

Returns 4095 even if you check with a multimeter the voltage going to the pin is below 3.3v.

This seems to happen only for analog inputs A1 and A2. ADC pins A0, A3, A4, A5 work great and return expected values proportional to the voltage on their pins.

Repro steps:

  • Flash latest atmel-samd MicroPython firmware on Feather M0 proto board (firmware built with BOARD=feather_m0_bluefruit_le)
  • Add potentiometer used as a variable resistor for checking analog inputs (3.3 volts to one end, ground to other end, middle pin/wiper to ADC input A1 or A2). Any variable voltage source could work though, just something to send some voltage to the ADC.
  • Try reading the ADC value and fiddling the knob to move between different voltages:
import machine
adc = machine.ADC(machine.Pin("A1"))
adc.read()
  • Notice only 4095 is returned (even when connected to ground).
@tannewt tannewt closed this as completed in 67372b3 Oct 7, 2016
tannewt pushed a commit that referenced this issue Aug 20, 2018
Merge updated Circuitpython
dhalbert pushed a commit that referenced this issue Jan 12, 2019
Add latest changes on repo
dhalbert pushed a commit that referenced this issue Dec 17, 2019
tannewt pushed a commit that referenced this issue May 12, 2020
add standard SPI support to QSPI for external flash
tannewt pushed a commit that referenced this issue May 26, 2020
@jepler jepler mentioned this issue Jun 25, 2020
tannewt pushed a commit that referenced this issue Sep 16, 2020
Small improvements to the dictionary compression
tannewt pushed a commit that referenced this issue Oct 1, 2020
It was incorrect to NULL out the pointer to our heap allocated buffer in
`reset`, because subsequent to framebuffer_reset, but while
the heap was still active, we could call `get_bufinfo` again,
leading to a fresh allocation on the heap that is about to be destroyed.

Typical stack trace:
```
#1  0x0006c368 in sharpdisplay_framebuffer_get_bufinfo
#2  0x0006ad6e in _refresh_display
#3  0x0006b168 in framebufferio_framebufferdisplay_background
#4  0x00069d22 in displayio_background
#5  0x00045496 in supervisor_background_tasks
#6  0x000446e8 in background_callback_run_all
#7  0x00045546 in supervisor_run_background_tasks_if_tick
#8  0x0005b042 in common_hal_neopixel_write
#9  0x00044c4c in clear_temp_status
#10 0x000497de in spi_flash_flush_keep_cache
#11 0x00049a66 in supervisor_external_flash_flush
#12 0x00044b22 in supervisor_flash_flush
#13 0x0004490e in filesystem_flush
#14 0x00043e18 in cleanup_after_vm
#15 0x0004414c in run_repl
#16 0x000441ce in main
```
When this happened -- which was inconsistent -- the display would keep
some heap allocation across reset which is exactly what we need to avoid.

NULLing the pointer in reconstruct follows what RGBMatrix does, and that
code is a bit more battle-tested anyway.

If I had a motivation for structuring the SharpMemory code differently,
I can no longer recall it.

Testing performed: Ran my complicated calculator program over multiple
iterations without observing signs of heap corruption.

Closes: #3473
ladyada pushed a commit that referenced this issue Jan 4, 2021
tannewt pushed a commit that referenced this issue Feb 10, 2021
tannewt pushed a commit that referenced this issue Apr 21, 2021
tannewt pushed a commit that referenced this issue Jun 23, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each
of p and q, even for values of p and q that have a difference earlier.
Accessing additional values is frequently done in practice, reading 4 or
more bytes from each input at a time for efficiency, so when completing
"non_exist<TAB>" in the repl, this causes a diagnostic:

    ==16938==ERROR: AddressSanitizer: global-buffer-overflow on
    address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
    READ of size 9 at 0x555555cd8dc8 thread T0
        #0 0x7ffff726457a  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
        #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
        #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
        #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
        #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
        #5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
        #6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
        #7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
        #8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni

    0x555555cd8dc8 is located 0 bytes to the right of global variable
    'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
    size 8
      'import_str' is ascii string 'import '

Signed-off-by: Jeff Epler <[email protected]>
jepler pushed a commit that referenced this issue Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant