CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.0.0-beta.2 2020-10-03T02:16:32+00:00 2020-10-03T02:16:32+00:00 Limor "Ladyada" Fried limor@ladyada.net 2020-10-03T02:16:32+00:00 urn:sha1:9535edb8f4be7a01158b75c78a2a56fe11e6d3f0 displayio: Fix matrixportal crash 2020-10-02T20:07:36+00:00 Jeff Epler jepler@gmail.com 2020-10-02T20:07:36+00:00 urn:sha1:b1592564b286ca7a5374e77eba2c2efc768ffae9 An RGBMatrix has no bus and no bus_free method. It is always possible to refresh the display. This was not a problem before, but the fix I suggested (#3449) added a call to core_bus_free when a FramebufferDisplay was being refreshed. This was not caught during testing. This is a band-aid fix and it brings to light a second problem in which a SharpDisplay + FrameBuffer will not have a 'bus' object, and yet does operate using a shared SPI bus. This kind of display will need a "bus-free" like function to be added, or it can have problems like #3309. 2020-10-01T18:00:25+00:00 Scott Shawcroft scott@adafruit.com 2020-10-01T18:00:25+00:00 urn:sha1:b9890f2d420665a96fcf56e196d36d0fc1032b66 sharpdisplay: Fix memory corruption across soft-reset 2020-10-01T17:54:48+00:00 Scott Shawcroft scott@adafruit.com 2020-10-01T17:54:48+00:00 urn:sha1:f303fb3d4103871e096699d5dcd4b419ac8acc3b Add Metro ESP32S2 2020-10-01T17:13:13+00:00 Scott Shawcroft scott@adafruit.com 2020-10-01T17:13:13+00:00 urn:sha1:be6e6eabd27e5e301decc93496a9fbc59f0f6bda Sdcard odb fix 2020-10-01T14:22:09+00:00 Jeff Epler jepler@gmail.com 2020-10-01T14:21:39+00:00 urn:sha1:d7c3f811afd924bae8e0b009a4cfadd6fab29584 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 2020-09-30T22:25:58+00:00 FoamyGuy foamyguy@gmail.com 2020-09-30T22:25:58+00:00 urn:sha1:422a7d4013ddaec7df5df9104e5d9ea533b31d1a 2020-09-30T19:57:39+00:00 Scott Shawcroft scott@tannewt.org 2020-09-29T20:04:39+00:00 urn:sha1:a739d314f1a9f5fee6517eb425a2c691969fd7f7 Also fix two bugs: * Crash when resetting board.SPI when it hasn't been inited. * Reading back the output value is always false. Fixes #3353 2020-09-30T19:03:10+00:00 Scott Shawcroft scott@adafruit.com 2020-09-30T19:03:10+00:00 urn:sha1:5ac3c36d64cf4be13e7a1ebc0c47fb546e689134 New quirk for sh1107 2020-09-30T19:03:03+00:00 FoamyGuy foamyguy@gmail.com 2020-09-30T19:03:03+00:00 urn:sha1:d1bda47d94c2ab9e42a74de4a5209df73e46a4ea