Initial SPI support not working at MicroPython layer #16
Labels
Comments
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 17, 2023
Starting with 2757acf, the `top` variable in `nlr_jump()` in `nlraarch64.c` was assigned to register `x19` by the compiler. However, the assembly code writes over that register with ldp x19, x20, [%0, adafruit#32] since `%0` is now `x19`. This causes the next line ldp lr, x9, [%0, adafruit#16] to load the wrong values. To fix the issue, we move the value of the `top` variable from an unknown register to a known register at the beginning of the asm code then only use known/hard-coded registers after that. Fixes issue micropython#11754. Signed-off-by: David Lechner <[email protected]>
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 <[email protected]> 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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As a quick test I tried out SPI with the MAX31855 thermocouple sensor, but it looks like at least with read calls you only get back 0x00 value bytes.
Example usage:
The result from spi.read(4) is a byte string with 4 zero values, however if you look at the trace on the wires with a Saleae we're actually receiving data from the chip (channel 0 is CS, channel 1 is clock, channel 2 is the data out / MISO line with the response data from the chip, it's not all zeros):
Likely there's some plumbing to be done to get the MicroPython SPI interface working with what's supported internally for SPI flash. Opening bug as a reminder and example to test with later since SPI is still a work in progress.
The text was updated successfully, but these errors were encountered: