CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=fix_typo_spanish 2020-10-17T02:31:32+00:00 2020-10-17T02:31:32+00:00 Jeff Epler jeff@adafruit.com 2020-10-17T02:31:32+00:00 urn:sha1:3c05a8c68cececcfb38eeefa6208afad2c56d215 Fix inconsistent supervisor heap 2020-10-13T01:43:21+00:00 Scott Shawcroft scott@tannewt.org 2020-10-13T01:36:18+00:00 urn:sha1:379e73af2e55b1f0c517883360e29d5dbc27a20b Fixes #3504 hopefully. 2020-10-07T22:23:47+00:00 Scott Shawcroft scott@tannewt.org 2020-09-29T02:21:17+00:00 urn:sha1:09bc4157516dd59754a3eb1a5dbbb72a758ebe93 This unifies the flash config to the settings used by the Boot ROM. This makes the config unique per board which allows for changing quad enable and status bit differences per flash device. It also allows for timing differences due to the board layout. This change also tweaks linker layout to leave more ram space for the CircuitPython heap. 2020-10-02T21:07:07+00:00 Christian Walther cwalther@gmx.ch 2020-10-02T21:07:07+00:00 urn:sha1:be8092f4d32d06488df88294a9dc4bb809411c5e 2020-10-02T21:03:21+00:00 Christian Walther cwalther@gmx.ch 2020-09-29T20:21:29+00:00 urn:sha1:5bdb8c45dd2700941ab75661b773680bdd46aaf1 This requires recovering the pointer of the allocation, which could be done by adding up neighbor lengths, but the simpler way is to stop NULLing it out in the first place and instead mark an allocation as freed by the client by setting the lowest bit of the length (which is always zero in a valid length). 2020-10-02T21:03:21+00:00 Christian Walther cwalther@gmx.ch 2020-09-28T20:34:02+00:00 urn:sha1:d6d02c67d2bcacaa02499930aabd76365797b108 When allocations were freed in a different order from the reverse of how they were allocated (leaving holes), the heap would get into an inconsistent state, eventually resulting in crashes. free_memory() relies on having allocations in order, but allocate_memory() did not guarantee that: It reused the first allocation with a NULL ptr without ensuring that it was between low_address and high_address. When it belongs to a hole in the allocated memory, such an allocation is not really free for reuse, because free_memory() still needs its length. Instead, explicitly mark allocations available for reuse with a special (invalid) value in the length field. Only allocations that lie between low_address and high_address are marked that way. 2020-10-01T18:18:36+00:00 Scott Shawcroft scott@adafruit.com 2020-10-01T18:18:36+00:00 urn:sha1:d62ac24493abb7aadcf68751997092a1b4141b01 Add some NORETURN attributes 2020-09-29T05:44:30+00:00 microDev 70126934+microDev1@users.noreply.github.com 2020-09-29T05:44:30+00:00 urn:sha1:4c7d9e3aafbde08399d9839d6cde968f4d1ae005 2020-09-28T23:55:56+00:00 Jeff Epler jepler@gmail.com 2020-09-24T16:20:32+00:00 urn:sha1:726dcdb60aa84b5070e5484a19e896abdaffeb93 I have a function where it should be impossible to reach the end, so I put in a safe-mode reset at the bottom: ``` int find_unused_slot(void) { // precondition: you already verified that a slot was available for (int i=0; i<NUM_SLOTS; i++) { if( slot_free(i)) { return i; } } safe_mode_reset(MICROPY_FATAL_ERROR); } ``` However, the compiler still gave a diagnostic, because safe_mode_reset was not declared NORETURN. So I started by teaching the compiler that reset_into_safe_mode never returned. This leads at least one level deeper due to reset_cpu needing to be a NORETURN function. Each port is a little different in this area. I also marked reset_to_bootloader as NORETURN. Additional notes: * stm32's reset_to_bootloader was not implemented, but now does a bare reset. Most stm32s are not fitted with uf2 bootloaders anyway. * ditto cxd56 * esp32s2 did not implement reset_cpu at all. I used esp_restart(). (not tested) * litex did not implement reset_cpu at all. I used reboot_ctrl_write. But notably this is what reset_to_bootloader already did, so one or the other must be incorrect (not tested). reboot_ctrl_write cannot be declared NORETURN, as it returns unless the special value 0xac is written), so a new unreachable forever-loop is added. * cxd56's reset is via a boardctl() call which can't generically be declared NORETURN, so a new unreacahble "for(;;)" forever-loop is added. * In several places, NVIC_SystemReset is redeclared with NORETURN applied. This is accepted just fine by gcc. I chose this as preferable to editing the multiple copies of CMSIS headers where it is normally declared. * the stub safe_mode reset simply aborts. This is used in mpy-cross. 2020-09-24T21:57:20+00:00 Jeff Epler jepler@gmail.com 2020-09-24T21:57:10+00:00 urn:sha1:6bcbe51f7fcfaca6ee3ee40b4ce64fd791725e8f