Minor fixes - #12

Minor fixes

Fixes #12

Ugfx yield

add #define CONFIG_ESP32_WIFI_RX_BUFFER_NUM 25 刣

Fixes the execution of py files with globals vars

Update from adafruit/main

Add LCD Module

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

Signed-off-by: Matthias Urlichs <[email protected]>

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, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#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, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#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]>

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, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#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, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#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]>

Bug micropython#8 (MEDIUM): Overflow in list concatenation
Bug micropython#12 (MEDIUM): Overflow in slice assignment
Bug micropython#19 (HIGH): Memory allocation overflow in list extend

FIXES:

1. List Concatenation (lines 119-122):
   - Addition o->len + p->len can overflow SIZE_MAX
   - Causes undersized buffer allocation
   - Fixed: Check o->len > SIZE_MAX - p->len before addition

2. Slice Assignment (line 195):
   - Check self->len + len_adj > self->alloc overflows before comparing
   - Fixed: Rewrite as len_adj > self->alloc - self->len

3. List Extend - Double Overflow (lines 253-267):
   - Two overflows: (a) self->len + arg->len + 4
   - (b) sizeof(mp_obj_t) * arg->len in memcpy
   - Fixed: Check both conditions before allocation and memcpy

Impact: Prevents heap corruption from integer overflow in list operations

File: py/objlist.c
Severity: HIGH + 3 MEDIUM

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

Signed-off-by: Matthias Urlichs <[email protected]>

CLAUDE.local.md:
- Update STM32WB55 status with multitest results (7/18 pass)
- Document missing features (NOTIFY callbacks, MTU, pairing, L2CAP)
- Move from "Active Work" to "Recent Work" (scheduler integration complete)
- Update Issue #12 description with refactor details

docs/ZEPHYR_BLE_FREERTOS_PLAN.md:
- New document outlining FreeRTOS integration strategy
- Migration path from scheduler-based to task-based architecture
- Timeline and testing requirements

Signed-off-by: Andrew Leech <[email protected]>

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, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#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, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#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]>

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 5d4bd95

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, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#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, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#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]>