Analog input with string instead of machine.Pin instance fails without error #12
Labels
Comments
jepler
added a commit
to jepler/circuitpython
that referenced
this issue
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
added a commit
to jepler/circuitpython
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 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
cwalther
pushed a commit
to cwalther/circuitpython
that referenced
this issue
Jun 1, 2024
Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, adafruit#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, adafruit#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, adafruit#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, adafruit#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, adafruit#12] 95e6: 6105 str r5, [r0, adafruit#16] 95e8: 6146 str r6, [r0, adafruit#20] 95ea: 6187 str r7, [r0, adafruit#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, adafruit#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, adafruit#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, adafruit#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, adafruit#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, adafruit#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, adafruit#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not a high priority but it looks like accidentally configuring a ADC using a pin string name will succeed:
However attempting to read values with read() will just return max value 4095.
The right way for this to work is to send a machine.Pin instance like:
Then the values are read as expected. However it's odd that passing a string vs. machine.Pin succeeds and doesn't fail with an error. Ideally we should catch this and throw an error that tells the user they need to specify a pin instance.
The text was updated successfully, but these errors were encountered: