port_YIELD_FROM_ISR() in custom C module for micropython causing linker error

[CtlAltDel]

Hi all,

Asking here since I'm not getting any response on the ESP32 forum on the Micropython site:

ESP-IDF version: v5.1.2-dirty

I have a custom board design that uses an ESP32-PICO-D4. On this board is a SC16IS752 dual SPI UART, accessed from MP via a custom C module. I have found that characters are dropped, particularly at higher baud rates, due to the time that MP GPIO interrupts require. So, I would like to have the UART received character interrupt served via a FreeRTOS task, Adding a test function that creates a task that blinks an LED while running in parallel with the MP task was not a problem, however when trying to add support for a GPIO interrupt to service the UART IRQ I found that portYIELD_FROM_ISR() was preventing the module from successfully linking, generating the following error message:

spisvc.c:(.iram1.0+0x21): undefined reference to traceISR_EXIT_TO_SCHEDULER

Here is the relevant part of the task that sets up the interrupt handler:

Code: [Select all] [Expand/Collapse]

1.     gpio_isr_handler_add(GPIO_NUM_34, spi_uart_isr_handler, NULL);
2.    
3.     for (;;) {
4.        xSemaphoreTake(spi_svc_sem, portMAX_DELAY);
5.        gpio_set_level(GPIO_NUM_12, 1);
6.        spisvc_uart_rx_fifos();
7.        gpio_set_level(GPIO_NUM_12, 0);
8.     }

GeSHi © Codebox Plus Extension

And here is the (barebones) handler itself:

Code: [Select all] [Expand/Collapse]

1. void spi_uart_isr_handler(void *param)
2. {
3.     static BaseType_t xHigherPriorityTaskWoken = pdFALSE;
4.        
5.     xSemaphoreGiveFromISR(spi_svc_sem, &xHigherPriorityTaskWoken);
6.     if( xHigherPriorityTaskWoken) {
7.         portYIELD_FROM_ISR();
8.     }
9. }

GeSHi © Codebox Plus Extension

If I comment out portYIELD_FROM_ISR() it compiles and links without a problem, I'm assuming I need to link to some library or include some header that defines traceISR_EXIT_TO_SCHEDULER?

If I add a call to vTaskDelay() there are no problems, so it doesn't seem to be a FreeRTOS library issue.

Any help greatly appreciated!