micropython/ports/rp2/mpnetworkport.c

125 wiersze
3.8 KiB
C
Czysty Zwykły widok Historia

/*
* This file is part of the MicroPython project, http://micropython.org/
*
* The MIT License (MIT)
*
* Copyright (c) 2014 Damien P. George
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include "py/runtime.h"
#include "py/mphal.h"
#include "pendsv.h"
#if MICROPY_PY_LWIP
#include "shared/runtime/softtimer.h"
#include "lwip/timeouts.h"
// Poll lwIP every 64ms by default
#define LWIP_TICK_RATE_MS 64
// Soft timer for running lwIP in the background.
static soft_timer_entry_t mp_network_soft_timer;
#if MICROPY_PY_NETWORK_CYW43
#include "lib/cyw43-driver/src/cyw43.h"
#include "lib/cyw43-driver/src/cyw43_stats.h"
#include "hardware/irq.h"
#define CYW43_IRQ_LEVEL GPIO_IRQ_LEVEL_HIGH
#define CYW43_SHARED_IRQ_HANDLER_PRIORITY PICO_SHARED_IRQ_HANDLER_HIGHEST_ORDER_PRIORITY
rp2: Fix lightsleep to work with interrupts and cyw43 driver. This commit prevents the device from "hanging" when using lightsleep while the WiFi chip is active. Whenever the WiFi chip wants to interrupt the microcontroller to notify it for a new package, it sets the CYW43_PIN_WL_HOST_WAKE pin to high, triggering an IRQ. However, as polling the chip cannot happen in an interrupt handler, it subsequently notifies the pendsv-service to do a poll as soon as the interrupt handler ended. In order to prevent a new interrupt from happening immediately afterwards, even before the poll has run, the IRQ handler disables interrupts from the pin. The first problem occurs, when a WiFi package arrives while the main loop is in cyw43-code. In order to prevent concurrent access of the hardware, the network code blocks pendsv from running again while entering lwIP code. The same holds for direct cyw43 code (like changing the cyw43-gpios, i.e. the LED on the Pico W). While the pendsv is disabled, interrupts can still occur to schedule a poll (and disable further interrupts), but it will not run. This can happen while the microcontroller is anywhere in rp2040 code. In order to preserve power while waiting for cyw43 responses, cyw43_configport.h defines CYW43_DO_IOCTL_WAIT and CYW43_SDPCM_SEND_COMMON_WAIT to __WFI(). While this might work in most cases, there are 2 edge cases where it fails: - When an interrupt has already been received by the cyw43 stack, for example due to an incoming ethernet packet. - When the interrupt from the cyw43 response comes before the microcontroller entered the __WFI() instruction. When that happens, wfi will just block forever as no further interrupts are received. The only way to safely use wfi to wake up from an interrupt is inside a critical section, as this delays interrupts until the wfi is entered, possibly resuming immediately until interrupts are reenabled and the interrupt handler is run. Additionally this critical section needs to check whether the interrupt has already been disabled and pendsv was triggered, as in such a case, wfi can never be woken up, and needs to be skipped, because there is already a package from the network chip waiting. Note that this turns cyw43_yield into a nop (and thereby the cyw43-loops into busy waits) from the second time onwards, as after the first call, a pendsv request will definitely be pending. More logic could be added, to explicitly enable the interrupt in this case. Regarding lightsleep, this code has a similar problem. When an interrupt occurs during lightsleep, the IRQ and pendsv handler and thereby poll are run immediately, with the clocks still disabled, causing the SPI transfers to fail. If we don't want to add complex logic inside the IRQ handler we need to protect the whole lightsleep procedure form interrupts with a critical section, exiting out early if an interrupt is pending for whatever reason. Only then we can start to shut down clocks and only enable interrupts when the system is ready again. Other interrupt handlers might also be happy, that they are only run when the system is fully operational. Tested on a Pico W, calling machine.lightsleep() within an endless loop and pinging from the outside.
2022-09-27 09:37:34 +00:00
volatile int cyw43_has_pending = 0;
static void gpio_irq_handler(void) {
uint32_t events = gpio_get_irq_event_mask(CYW43_PIN_WL_HOST_WAKE);
if (events & CYW43_IRQ_LEVEL) {
// As we use a high level interrupt, it will go off forever until it's serviced.
// So disable the interrupt until this is done. It's re-enabled again by
// CYW43_POST_POLL_HOOK which is called at the end of cyw43_poll_func.
gpio_set_irq_enabled(CYW43_PIN_WL_HOST_WAKE, CYW43_IRQ_LEVEL, false);
rp2: Fix lightsleep to work with interrupts and cyw43 driver. This commit prevents the device from "hanging" when using lightsleep while the WiFi chip is active. Whenever the WiFi chip wants to interrupt the microcontroller to notify it for a new package, it sets the CYW43_PIN_WL_HOST_WAKE pin to high, triggering an IRQ. However, as polling the chip cannot happen in an interrupt handler, it subsequently notifies the pendsv-service to do a poll as soon as the interrupt handler ended. In order to prevent a new interrupt from happening immediately afterwards, even before the poll has run, the IRQ handler disables interrupts from the pin. The first problem occurs, when a WiFi package arrives while the main loop is in cyw43-code. In order to prevent concurrent access of the hardware, the network code blocks pendsv from running again while entering lwIP code. The same holds for direct cyw43 code (like changing the cyw43-gpios, i.e. the LED on the Pico W). While the pendsv is disabled, interrupts can still occur to schedule a poll (and disable further interrupts), but it will not run. This can happen while the microcontroller is anywhere in rp2040 code. In order to preserve power while waiting for cyw43 responses, cyw43_configport.h defines CYW43_DO_IOCTL_WAIT and CYW43_SDPCM_SEND_COMMON_WAIT to __WFI(). While this might work in most cases, there are 2 edge cases where it fails: - When an interrupt has already been received by the cyw43 stack, for example due to an incoming ethernet packet. - When the interrupt from the cyw43 response comes before the microcontroller entered the __WFI() instruction. When that happens, wfi will just block forever as no further interrupts are received. The only way to safely use wfi to wake up from an interrupt is inside a critical section, as this delays interrupts until the wfi is entered, possibly resuming immediately until interrupts are reenabled and the interrupt handler is run. Additionally this critical section needs to check whether the interrupt has already been disabled and pendsv was triggered, as in such a case, wfi can never be woken up, and needs to be skipped, because there is already a package from the network chip waiting. Note that this turns cyw43_yield into a nop (and thereby the cyw43-loops into busy waits) from the second time onwards, as after the first call, a pendsv request will definitely be pending. More logic could be added, to explicitly enable the interrupt in this case. Regarding lightsleep, this code has a similar problem. When an interrupt occurs during lightsleep, the IRQ and pendsv handler and thereby poll are run immediately, with the clocks still disabled, causing the SPI transfers to fail. If we don't want to add complex logic inside the IRQ handler we need to protect the whole lightsleep procedure form interrupts with a critical section, exiting out early if an interrupt is pending for whatever reason. Only then we can start to shut down clocks and only enable interrupts when the system is ready again. Other interrupt handlers might also be happy, that they are only run when the system is fully operational. Tested on a Pico W, calling machine.lightsleep() within an endless loop and pinging from the outside.
2022-09-27 09:37:34 +00:00
cyw43_has_pending = 1;
__SEV();
pendsv_schedule_dispatch(PENDSV_DISPATCH_CYW43, cyw43_poll);
CYW43_STAT_INC(IRQ_COUNT);
}
}
void cyw43_irq_init(void) {
gpio_add_raw_irq_handler_with_order_priority(CYW43_PIN_WL_HOST_WAKE, gpio_irq_handler, CYW43_SHARED_IRQ_HANDLER_PRIORITY);
irq_set_enabled(IO_IRQ_BANK0, true);
NVIC_SetPriority(PendSV_IRQn, PICO_LOWEST_IRQ_PRIORITY);
}
void cyw43_post_poll_hook(void) {
rp2: Fix lightsleep to work with interrupts and cyw43 driver. This commit prevents the device from "hanging" when using lightsleep while the WiFi chip is active. Whenever the WiFi chip wants to interrupt the microcontroller to notify it for a new package, it sets the CYW43_PIN_WL_HOST_WAKE pin to high, triggering an IRQ. However, as polling the chip cannot happen in an interrupt handler, it subsequently notifies the pendsv-service to do a poll as soon as the interrupt handler ended. In order to prevent a new interrupt from happening immediately afterwards, even before the poll has run, the IRQ handler disables interrupts from the pin. The first problem occurs, when a WiFi package arrives while the main loop is in cyw43-code. In order to prevent concurrent access of the hardware, the network code blocks pendsv from running again while entering lwIP code. The same holds for direct cyw43 code (like changing the cyw43-gpios, i.e. the LED on the Pico W). While the pendsv is disabled, interrupts can still occur to schedule a poll (and disable further interrupts), but it will not run. This can happen while the microcontroller is anywhere in rp2040 code. In order to preserve power while waiting for cyw43 responses, cyw43_configport.h defines CYW43_DO_IOCTL_WAIT and CYW43_SDPCM_SEND_COMMON_WAIT to __WFI(). While this might work in most cases, there are 2 edge cases where it fails: - When an interrupt has already been received by the cyw43 stack, for example due to an incoming ethernet packet. - When the interrupt from the cyw43 response comes before the microcontroller entered the __WFI() instruction. When that happens, wfi will just block forever as no further interrupts are received. The only way to safely use wfi to wake up from an interrupt is inside a critical section, as this delays interrupts until the wfi is entered, possibly resuming immediately until interrupts are reenabled and the interrupt handler is run. Additionally this critical section needs to check whether the interrupt has already been disabled and pendsv was triggered, as in such a case, wfi can never be woken up, and needs to be skipped, because there is already a package from the network chip waiting. Note that this turns cyw43_yield into a nop (and thereby the cyw43-loops into busy waits) from the second time onwards, as after the first call, a pendsv request will definitely be pending. More logic could be added, to explicitly enable the interrupt in this case. Regarding lightsleep, this code has a similar problem. When an interrupt occurs during lightsleep, the IRQ and pendsv handler and thereby poll are run immediately, with the clocks still disabled, causing the SPI transfers to fail. If we don't want to add complex logic inside the IRQ handler we need to protect the whole lightsleep procedure form interrupts with a critical section, exiting out early if an interrupt is pending for whatever reason. Only then we can start to shut down clocks and only enable interrupts when the system is ready again. Other interrupt handlers might also be happy, that they are only run when the system is fully operational. Tested on a Pico W, calling machine.lightsleep() within an endless loop and pinging from the outside.
2022-09-27 09:37:34 +00:00
cyw43_has_pending = 0;
gpio_set_irq_enabled(CYW43_PIN_WL_HOST_WAKE, CYW43_IRQ_LEVEL, true);
}
#endif
#if MICROPY_PY_NETWORK_WIZNET5K
void wiznet5k_poll(void);
void wiznet5k_deinit(void);
void wiznet5k_try_poll(void) {
pendsv_schedule_dispatch(PENDSV_DISPATCH_WIZNET, wiznet5k_poll);
}
#endif
u32_t sys_now(void) {
// Used by LwIP
return mp_hal_ticks_ms();
}
void lwip_lock_acquire(void) {
// Prevent PendSV from running.
pendsv_suspend();
}
void lwip_lock_release(void) {
// Allow PendSV to run again.
pendsv_resume();
}
// This is called by soft_timer and executes at PendSV level.
static void mp_network_soft_timer_callback(soft_timer_entry_t *self) {
// Run the lwIP internal updates.
sys_check_timeouts();
#if MICROPY_PY_NETWORK_WIZNET5K
wiznet5k_poll();
#endif
}
void mod_network_lwip_init(void) {
soft_timer_static_init(
&mp_network_soft_timer,
SOFT_TIMER_MODE_PERIODIC,
LWIP_TICK_RATE_MS,
mp_network_soft_timer_callback
);
soft_timer_reinsert(&mp_network_soft_timer, LWIP_TICK_RATE_MS);
}
#endif // MICROPY_PY_LWIP