nvs_set_blob issue with UART interrupt enabled

[amruta]

Hello,

We have an application running both BLE and WiFi. MQTT is used to communicate with server. It uses UART read interrupt to communicate with a third party device.
We are trying to read/write data in nvs memory. NVS read is working fine but while writing it gets stuck and control never returns back from nvs_set_blob.
Disabling UART interrupt before nvs write had no effect. Calling uart_driver_delete seems to be working. Is there any other way to do this?

ESP IDF: v3.1-dirty
Below is the UART configuration used

Code: Select all

    
    uart_config_t uart_config = {
        .baud_rate = 4800, 
        .data_bits = UART_DATA_8_BITS,
        .parity = UART_PARITY_EVEN,
        .stop_bits = UART_STOP_BITS_1,
        .flow_ctrl = UART_HW_FLOWCTRL_DISABLE};

    uart_param_config(UART_NUM_2, &uart_config);
    uart_set_pin(UART_NUM_2, 17, 16, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);
    uart_driver_install(UART_NUM_2, 1024* 2, 0, 0, NULL, 0);
    uart_set_line_inverse(UART_NUM_2, UART_INVERSE_TXD | UART_INVERSE_RXD);
    uart_isr_free(UART_NUM_2);
    uart_isr_register(UART_NUM_2, uart2_isr, NULL, ESP_INTR_FLAG_IRAM, &uart2_intr_handle);

Partition table

Code: Select all

otadata,  data, ota,     0xd000,  0x2000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  ota_0,   0x10000, 0x178000,
ota_1,    app,  ota_1,   ,        0x178000,
nvs,      data, nvs,     ,        0x10000,

[ESP_Angus]

Hi amruta,

Without seeing all the code it's hard to tell what the problem could be.

Are you calling nvs_set_blob from a task, or from inside the UART ISR? NVS APIs are not safe to use from interrupts.

If it's a task, is there a chance it's deadlocking with something that happens inside the ISR?

[ESP_Angus]

Ah, one other very likely thing I didn't spot the first time:

Code: Select all

    uart_isr_register(UART_NUM_2, uart2_isr, NULL, ESP_INTR_FLAG_IRAM, &uart2_intr_handle);
    

Are you sure that all of the code that can possibly be called from uart2_isr is in IRAM? If not, problems can occur while writing to flash and this could cause the exact symptom you're seeing (although more likely a panic handler crash, it's not guaranteed).

Try removing the ESP_INTR_FLAG_IRAM flag (set the flags value to 0) and see if the problem goes away. Without this flag, any UART interrupts that occur during an NVS write will be processed after the NVS write completes. With this flag, the interrupt will be processed immediately but must take care that only code/data in IRAM/DRAM is accessed.

More details can be found at https://docs.espressif.com/projects/esp ... t-handlers

[amruta]

Ah, one other very likely thing I didn't spot the first time:

Code: Select all

    uart_isr_register(UART_NUM_2, uart2_isr, NULL, ESP_INTR_FLAG_IRAM, &uart2_intr_handle);
   

Are you sure that all of the code that can possibly be called from uart2_isr is in IRAM? If not, problems can occur while writing to flash and this could cause the exact symptom you're seeing (although more likely a panic handler crash, it's not guaranteed).

Try removing the ESP_INTR_FLAG_IRAM flag (set the flags value to 0) and see if the problem goes away. Without this flag, any UART interrupts that occur during an NVS write will be processed after the NVS write completes. With this flag, the interrupt will be processed immediately but must take care that only code/data in IRAM/DRAM is accessed.

More details can be found at https://docs.espressif.com/projects/esp ... t-handlers

You are right !
ESP_INTR_FLAG_IRAM was the problem
And sorry for the (super) delayed reply