Digital output on A0 with DAC enabled doesn't work or fail #4
Comments
jepler
referenced
this issue
in jepler/circuitpython
Nov 25, 2019
It's probably not the whole story, however, this fixes a crash observed
when bulk copying data to an nRF board using `dd`.
Basically, the call stack looked like this when resetting into safe mode:
#0 reset_into_safe_mode reason=reason@entry=GC_ALLOC_OUTSIDE_VM
#1 gc_alloc
.. #4 external_flash_write_block
.. adafruit#11 usb_background
adafruit#12 run_background_tasks
adafruit#13 common_hal_neopixel_write
.. adafruit#18 start_mp
i.e., during early startup, it is not okay yet to call allocation functions
like m_malloc_maybe that use the garbage collected heap. However,
nRF's neopixel_write (which already includes special handling to avoid
heap allocations for the status pixel!) can enter background tasks, which
do nearly arbitrary things including heap allocations.
We re-use the same test that switches from heap allocation to stack
allocation for the pattern buffer.
jepler
referenced
this issue
in jepler/circuitpython
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 adafruit#5 0x00045496 in supervisor_background_tasks adafruit#6 0x000446e8 in background_callback_run_all adafruit#7 0x00045546 in supervisor_run_background_tasks_if_tick adafruit#8 0x0005b042 in common_hal_neopixel_write adafruit#9 0x00044c4c in clear_temp_status adafruit#10 0x000497de in spi_flash_flush_keep_cache adafruit#11 0x00049a66 in supervisor_external_flash_flush adafruit#12 0x00044b22 in supervisor_flash_flush adafruit#13 0x0004490e in filesystem_flush adafruit#14 0x00043e18 in cleanup_after_vm adafruit#15 0x0004414c in run_repl adafruit#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: adafruit#3473
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 <jepler@gmail.com>
microdev1
pushed a commit
that referenced
this issue
Mar 17, 2023
Pull in the latest main branch from adafruit
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This might be by design and isn't necessarily expected to be supported, but I noticed if I enable the DAC (which uses A0 as the output) I can still create a digital output for pin A0, like:
After running the above the A0 pin is still at 0V. This seems expected since only one thing can control that pin at a time, however it might be nice to fail in some way so the user knows they are doing something wrong. Perhaps if you try to use pin A0 as a digital output with the DAC enabled we catch that state and fail with an error.
Not a huge priority issue.
The text was updated successfully, but these errors were encountered: