Using the multicore lockout feature in the general atomic section makes itmuch more difficult to get correct.Signed-off-by: Damien George <damien@micropython.org>

These allow entering/exiting a mutex and also disabling/restoringinterrupts, in an atomic way.Signed-off-by: Damien George <damien@micropython.org>

Prior to this commit there is a potential deadlock inmp_thread_begin_atomic_section(), when obtaining the atomic_mutex, in thefollowing situation:- main thread calls mp_thread_begin_atomic_section() (for whatever reason,  doesn't matter)- the second core is running so the main thread grabs the mutex via the  call mp_thread_mutex_lock(&atomic_mutex, 1), and this succeeds- before the main thread has a chance to run save_and_disable_interrupts()  a USB IRQ comes in and the main thread jumps off to process this IRQ- that USB processing triggers a call to the dcd_event_handler() wrapper  from commitbcbdee2- that then calls mp_sched_schedule_node()- that then attempts to obtain the atomic section, calling  mp_thread_begin_atomic_section()- that call then blocks trying to obtain atomic_mutex- core0 is now deadlocked on itself, because the main thread has the mutex  but the IRQ handler (which preempted the main thread) is blocked waiting  for the mutex, which will never be freeThe solution in this commit is to use mutex enter/exit functions that alsoatomically disable/restore interrupts.Fixes issues#12980 and#13288.Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Nicko van Someren <nicko@nicko.org>

Do not wait in the worst case up to the timeout.Fixes issue#13377.Signed-off-by: robert-hh <robert@hammelrath.com>

The SysTick_Config function must use the system/CPU clock to configure theticks.Signed-off-by: iabdalkader <i.abdalkader@gmail.com>

Switch the RTC clock source to Sub-clock (XCIN). This board has anaccurate LSE crystal, and it should be used for the RTC clocksource.Signed-off-by: iabdalkader <i.abdalkader@gmail.com>

Adds support to asyncio.gather() for the case that one or more (or all)sub-tasks finish and/or raise an exception before the gather starts.Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Kwabena W. Agyeman <kwagyeman@live.com>

Prior to this commit it would skip every second cipher returned frommbedtls.The corresponding test is also updated and now passes on esp32, rp2, stm32and unix.Signed-off-by: Damien George <damien@micropython.org>

These separate drivers must share the DMA resource with each other.Fixes issue#13380.Signed-off-by: Damien George <damien@micropython.org>

If a return is executed within the try block of a try-finally then thereturn value is stored on the top of the Python stack during the executionof the finally block.  In this case the Python stack is one larger than itnormally would be in the finally block.Prior to this commit, the compiler was not taking this case into accountand could have a Python stack overflow if the Python stack used by thefinally block was more than that used elsewhere in the function.  In sucha scenario the last argument of the function would be clobbered by thetop-most temporary value used in the deepest Python expression/statement.This commit fixes that case by making sure enough Python stack is allocatedto the function.Fixes issue#13562.Signed-off-by: Damien George <damien@micropython.org>

Tested on Portenta C33 with AT24256B (addrsize=16) and SSD1306.Fixes issue#13280.Signed-off-by: Takeo Takahashi <takeo.takahashi.xv@renesas.com>

The pending_value_handle needs to be freed and reset before callingmp_bluetooth_gattc_on_read_write_status(), which will call the Python IRQhandler, which may in turn call back into BTstack to perform an action likea write.  In that case the pending_value_handle will need to be availablefor the write/read/etc to proceed.Fixes issue#13611.Signed-off-by: Damien George <damien@micropython.org>

Similar to the previous commit but for MP_BLUETOOTH_IRQ_GATTC_READ_DONE:the pending_value_handle needs to be reset before callingmp_bluetooth_gattc_on_read_write_status(), which will call the Python IRQhandler, which may in turn call back into BTstack to perform an action likea write.  In that case the pending_value_handle will need to be availablefor the write/read/etc to proceed.Fixes issue#13634.Signed-off-by: Damien George <damien@micropython.org>

In case callbacks must run (eg a disconnect event happens during thedeinit) and the GIL must be obtained to run the callback.Fixes part of issue#12349.Signed-off-by: Damien George <damien@micropython.org>

The Python BLE IRQ handler will most likely run on the NimBLE task, so itsC stack must be large enough to accommodate reasonably complicated Pythoncode (eg a few call depths).  So increase this stack size.Also increase the headroom from 1024 to 2048 bytes.  This is needed because(1) the esp32 architecture uses a fair amount of stack in general; and (2)by the time execution gets to setting the Python stack top via`mp_stack_set_top()` in this interlock code, about 600 bytes of stack arealready used, which reduces the amount available for Python.Fixes issue#12349.Signed-off-by: Damien George <damien@micropython.org>

Signed-off-by: Damien George <damien@micropython.org>