ESP32C6 design bootloader，gpio interrupt (IDFGH-14345)

[zzff-sys]

  I use ESP32C6 design bootloader，Need to use the gpio interrupt.Because design bootloader, so freertos System unavailable，so I need to rewrite the gpio driver function。For example：gpio_install_isr_service，gpio_isr_handler_add，gpio_isr_register，esp_intr_alloc_intrstatus
I have redesigned it, but now the problem is that my interrupt cannot be triggered when the system is running. After checking, the gpio interrupt failed to register, which I suspect is related to my rewritten function. Please help me analyze the rewritten function

[KonstantinKondrashov]

Hi @zzff-sys!
I wonder why you need to use GPIO interrupts in the bootloader. Could you provide more details about your specific use case? There might be alternative approaches we can suggest that better align with your requirements.

It's also important to note that ESP-IDF does not officially support using the GPIO driver in the bootloader. The bootloader operates in a minimal environment without FreeRTOS or the full ESP-IDF framework.

If you can share more about your goals, we can help explore other solutions that work within the constraints of the bootloader.

[zzff-sys]

@KonstantinKondrashov
First of all, thank you for your reply. The details are as follows:

1. We want to download uds, so we must develop boot.

2, use canfd driver chip, this chip is SPI to canfd protocol, need to receive external data through gpio interrupt

3. We need to develop uds and download it through canfd, and canfd needs to interrupt the corresponding port to receive data

[zzff-sys]

So in our own project, we tried to rework the gpio driver

[ginkgm]

Hi @zzff-sys ,

Sadly to say, the bootloader of ESP-IDF is designed to reduce any possibility of requiring to be updated. Interrupt and multi-threading (RTOS) are relatively unstable and can become a common cause of bug. I can see in the near future there won't be support for them in the bootloader.

If you want to add them into the bootloader, you will need to implement them yourself. But after adding them, there is no much difference between the bootloader and the app. Why not just do it in the app?

As for the driver in ESP-IDF, including GPIO and TWAI, they are designed to depends on some app-specific utilities like interrupt and FreeRTOS. So they can't be used in bootloader either.

If you want to implement your own driver that can be used in bootloader, the easiest way is to refactor from ESP-IDF drivers, removing all OS related code (and maybe the log also) and keep code from the HAL only.

But again, then why not do it in the app? Our suggestion is to add a flashing mode at the beginning of your app, detect the download mode and do the OTA in the app. The download code itself (a kind of bootloader, but still part of the app) can also be updated this way. This way you can make full use of all IDF features without much effort.

btw, we have a plan of allowing the app to upgrade the bootloader in progress. We can discuss about this below if you need it.

[zzff-sys]

@ginkgm
First of all, thank you for your reply. It is necessary for my project to develop bootloader based on esp32C6. As you said, I need to redesign the gpio interrupt correlation function and remove the freertos correlation. I redesigned the interrupt function as follows, I don't know if it is reasonable. During testing, there were times when an entry interrupt was successful, but then I couldn't get an entry interrupt for some reason, and I didn't change the code.
`esp_err_t gpio_esp_intr_alloc_intrstatus(int source, int flags, intr_handler_t handler,
void *arg, intr_handle_t *ret_handle)
{
static intr_handle_data_t ret;
int intr_num = 15;
uint32_t cpu = esp_cpu_get_core_id();

flags |= ESP_INTR_FLAG_LOWMED;
vector_desc_t *vd = get_desc_for_int(intr_num, cpu);
if (vd == NULL)
{
ESP_LOGE(TAG,"vd is NULL!");
return ESP_ERR_NO_MEM;
}

vd->flags = VECDESC_FL_NONSHARED;
if (handler) {
esp_cpu_intr_set_handler(intr_num, (esp_cpu_intr_handler_t)handler, arg);
}
else{
ESP_LOGE(TAG,"handler is NULL");
return ESP_ERR_INVALID_ARG;
}
vd->source = source;
vd->cpu = cpu;
vd->intno = intr_num;

if (flags & ESP_INTR_FLAG_IRAM) {
vd->flags |= VECDESC_FL_INIRAM;
non_iram_int_mask[cpu] &= ~(1<<intr_num);
} else {
vd->flags &= ~VECDESC_FL_INIRAM;
non_iram_int_mask[cpu] |= (1<<intr_num);
}

if (source>=0) {
esp_rom_route_intr_matrix(cpu, source, intr_num);
}
else {
ESP_LOGE(TAG,"esp_rom_route_intr_matrix fialed!");
return ESP_ERR_INVALID_ARG;
}

ret.vector_desc = vd;

//Enable int at CPU-level;
ESP_INTR_ENABLE(intr_num);

if (ret_handle != NULL)
{
*ret_handle = &ret;
}

ESP_LOGI(TAG,"source1:%d,flags1:%d,handler1:%p,arg1:%p,ret_handle1:%p\n",source,flags,handler,arg,ret_handle);
ESP_LOGI(TAG,"source:%d,flags:%d,intno:%d,cpu:%d\n",vd->source,vd->flags,vd->intno,vd->cpu);
ESP_LOGI(TAG, "Connected src %d to int %d (cpu %"PRIu32")", source, intr_num, cpu);
return ESP_OK;
}`

[zzff-sys]

I think it makes a lot of sense to develop your own bootloader based on ESP32, although you need to modify the relevant functions in the idf, but it makes a lot of engineering sense

[ESP-Marius]

Hard to tell what is wrong just from this snippet, but in general: supporting and debugging step-by-step how to implement X in the bootloader is a bit out of scope for github issues, as it would basically require us to re-explain every implementation detail in IDF.

If you have a question about a very specific detail (and the question contains sufficient background details to actually be able to answer it) then we might be able to help, otherwise I suggest:

• If this is an actual commercial project you can check out technical-inquiries
• Otherwise our forum can be used for any generic question: https://esp32.com/
• If you have a concrete feature or use-case you'd like to see supported in IDF you can submit it as a feature request

[zzff-sys]

thank you for your reply

[ESP-Marius]

Closing this one for now then. As already mentioned, if there is any questions about a specific technical detail then feel free to open another issue for it.

Thanks for your understanding!