Perhaps the queue is overflowing. As written, I think the interrupt handler might not wake the task that consumes from the queue, allowing the queue to keep growing until the next tick. I think it should be:Also, I think taskYIELD_FROM_ISR is preferred over portYIELD_FROM_ISR but I'm not familiar with FreeRTOS on RP2040 so maybe not.
Edit:
Actually, is it even valid to call portYIELD_FROM_ISR from DIO1_ISR? DIO1_ISR isn't actually an interrupt handler? The actual interrupt handler is gpio_default_irq_handler, which in turn invokes DIO1_ISR as a callback function. Instead of using the SDK's GPIO callback system, you could install your interrupt handler directly with the SDK's irq_set_exclusive_handler. Then there's no question of whether calling portYIELD_FROM_ISR is legit.
Code:
void __not_in_flash_func(DIO1_ISR)(uint gpio, uint32_t events){ BaseType_t wake_task = false; xQueueSendFromISR(phy_p->queue, &event_PHY_PROCESS_IRQ, &wake_task); portYIELD_FROM_ISR(wake_task);}Edit:
Actually, is it even valid to call portYIELD_FROM_ISR from DIO1_ISR? DIO1_ISR isn't actually an interrupt handler? The actual interrupt handler is gpio_default_irq_handler, which in turn invokes DIO1_ISR as a callback function. Instead of using the SDK's GPIO callback system, you could install your interrupt handler directly with the SDK's irq_set_exclusive_handler. Then there's no question of whether calling portYIELD_FROM_ISR is legit.
Statistics: Posted by alastairpatrick — Mon Mar 25, 2024 5:53 pm