Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp_partition_write doesn't work on encrypted partition (IDFGH-4423) #6254

Closed
2 of 4 tasks
jarcos-al opened this issue Dec 11, 2020 · 24 comments
Closed
2 of 4 tasks

esp_partition_write doesn't work on encrypted partition (IDFGH-4423) #6254

jarcos-al opened this issue Dec 11, 2020 · 24 comments
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@jarcos-al
Copy link

jarcos-al commented Dec 11, 2020

Environment

  • Development Kit: [none]
  • Module or chip used: ESP32-WROVER-E (16Mb SPIFlash, 64Mb SPRAM)
  • IDF version (run git describe --tags to find it): v4.3-dev-dirty
  • Build System: CMake
  • Compiler version (run xtensa-esp32-elf-gcc --version to find it): esp-2020r2-8.2.0
  • Operating System: Linux
  • Using an IDE?: Yes (Eclipse 2020-09(4.17.0))
  • Power Supply: external 3.3V

Problem Description

Hello, I have a problem with the flash encryption feature in my project. I have followed the steps that appear in the example esp-idf/examples/security/flash_encryption but when the program executes the function "esp_partition_write", the task hangs and does not continue. Furthermore any exception appears, only appears logs coming from task wdt because the task is hanged.

The data length that I am trying to write is multiple of 16 (128 bytes) with a offset 0. The partition is marked with the "encrypted" flag in the partition table.

If I remove the "encrypted" flag, the process runs correctly

Other items if possible

  • sdkconfig file (attach the sdkconfig file from your project folder)
  • Partitions table
  • elf file in the build folder (note this may contain all the code details and symbols of your project.)
  • coredump (This provides stacks of tasks.)

files.zip

@github-actions github-actions bot changed the title esp_partition_write doesn't work on encrypted partition esp_partition_write doesn't work on encrypted partition (IDFGH-4423) Dec 11, 2020
@Alvin1Zhang
Copy link
Collaborator

@jarcos-al Thanks for reporting and letting us know, we will look into.

@mahavirj
Copy link
Member

@jarcos-al Can you please provide your test application or minimal test code that reproduces this problem?

@jarcos-al
Copy link
Author

jarcos-al commented Dec 14, 2020

@mahavirj This is the function code that reproduces this problem. Is a function console command that write in the encrypted flash partition the data entered by keyboard.

static int set_credentials(int argc, char** argv){

  char uid_x[128] = {0};
  char apikey_x[128] = {0};

  const esp_partition_t* partition = esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_ANY,"server_keys");

   esp_err_t nerrors = arg_parse(argc, argv, (void**) &credentials_args);
   if (nerrors != 0) {
	   arg_print_errors(stderr, credentials_args.end, argv[0]);
	   return 1;
   }
  nerrors = esp_partition_erase_range(partition, 0, partition->size);

  if (credentials_args.uid->count == 0) {
	  ESP_LOGW("CREDENTIALS", "UID not setted, This field will be setted at default value");
	  credentials_args.uid->sval[0] = B_UID;
  }

  uint8_t uid_len = strlen(credentials_args.uid->sval[0]);
  ESP_LOGI("CREDENTIALS", "UID length %d",uid_len);
  if (uid_len < 1 ) {
	  ESP_LOGE("CREDENTIALS", "Data length must be greater than 0");
  }else{
	  memcpy(&uid_x[0],&uid_len,1);
	  memcpy(&uid_x[1],&credentials_args.uid->sval[0][0],uid_len);

	  /*Write UID*/
              nerrors = esp_partition_write(partition, 0, (void*)&uid_x[0], 128);
	  if(nerrors != ESP_OK){
		  ESP_LOGE("CREDENTIALS", "Error %d to write UID", nerrors);
		  return -1;
	  }
  }

  if (credentials_args.apikey->count == 0) {
	  ESP_LOGW("CREDENTIALS", "APIKEY not setted, This field will be setted at default value");
	  credentials_args.apikey->sval[0] = B_APIKEY;
  }

  uint8_t apikey_len = strlen(credentials_args.apikey->sval[0]);
  ESP_LOGI("CREDENTIALS", "APIKEY length %d",apikey_len);
  if (apikey_len < 1 ) {
	  ESP_LOGE("CREDENTIALS", "Data length must be greater than 0");
  }else{
	  memcpy(&apikey_x[0],&apikey_len,1);
	  memcpy(&apikey_x[1],&credentials_args.apikey->sval[0][0],apikey_len);

	  /*Write APIKEY*/
              nerrors = esp_partition_write(partition, 128, (void*)&apikey_x[0], 128);
	  if(nerrors != ESP_OK){
		  ESP_LOGE("CREDENTIALS", "Error %d to write APIKEY", nerrors);
		  return -1;
	  }
  }

  nvs_handle_t my_handle;
  esp_err_t err = nvs_open_from_partition("nvs","storage", NVS_READWRITE, &my_handle);
  if (err != ESP_OK) {
	  printf("Error (%s) opening NVS handle!\n", esp_err_to_name(err));
	  return -1;
  } else {
	  err = nvs_set_u8(my_handle, NVS_CREDENTIALS_STATUS_KEY, 1);
	  printf((err != ESP_OK) ? "Failed!\n" : "Done\n");
	  bool status = true;
	  if(err != ESP_OK){
		  printf((err != ESP_OK) ? "Failed!\n" : "Done\n");
		  ESP_LOGE("CREDENTIALS", "Error %d to write STATUS", err);
		  status = false;
	  }

	  // Commit written value.
	  // After setting any values, nvs_commit() must be called to ensure changes are written
	  // to flash storage. Implementations may write to storage at other times,
	  // but this is not guaranteed.
	  printf("Committing updates in NVS ... ");
	  err = nvs_commit(my_handle);
	  printf((err != ESP_OK) ? "Failed!\n" : "Done\n");

	  // Close
	  nvs_close(my_handle);

	  if(status){
		  GiveCredentialsSem();
	  }
  }

  return 0;
}

@jarcos-al
Copy link
Author

jarcos-al commented Dec 14, 2020

When I debug this program, the program is stuck at this point
imagen

@jarcos-al
Copy link
Author

@jarcos-al Can you please provide your test application or minimal test code that reproduces this problem?

Is something known if in future versions this problem is solved?

@mahavirj
Copy link
Member

@jarcos-al

In which task context you call set_credentials? What is its stack size? Also can you please provide console log that you see at your end? I can try to recreate based on your application that builds with v4.3 tag you mentioned.

@jarcos-al
Copy link
Author

@jarcos-al

In which task context you call set_credentials? What is its stack size? Also can you please provide console log that you see at your end? I can try to recreate based on your application that builds with v4.3 tag you mentioned.

The task that manage this function is console_repl. Is a function that is called by a console command. THe stack size of this task is 8000.
I attached the logs of the pr4ogram when i run this command.
logs.txt

@mahavirj
Copy link
Member

mahavirj commented Dec 18, 2020

@jarcos-al

Can you please try changing following config option values to their default ones:

CONFIG_SPI_FLASH_ERASE_YIELD_DURATION_MS=20
CONFIG_SPI_FLASH_ERASE_YIELD_TICKS=1

You have value for CONFIG_SPI_FLASH_ERASE_YIELD_TICKS as 0, any specific reason why you did that?

@jarcos-al
Copy link
Author

@jarcos-al

Can you please try changing following config option values to their default ones:

CONFIG_SPI_FLASH_ERASE_YIELD_DURATION_MS=20
CONFIG_SPI_FLASH_ERASE_YIELD_TICKS=1

You have value for CONFIG_SPI_FLASH_ERASE_YIELD_TICKS as 0, any specific reason why you did that?

I have made the changes you have told me, but the problem has not been solved yet

@mahavirj
Copy link
Member

@jarcos-al

It is difficult to comment without reproducible application. Problem lies somewhere in task which is keeping CPU occupied for prolonged duration without yielding. You may read more on this at https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/wdts.html#task-watchdog-timer. One question: do you observe same behavior if you reduce partition size from 5M to something smaller?

@jarcos-al
Copy link
Author

@jarcos-al

It is difficult to comment without reproducible application. Problem lies somewhere in task which is keeping CPU occupied for prolonged duration without yielding. You may read more on this at https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/wdts.html#task-watchdog-timer. One question: do you observe same behavior if you reduce partition size from 5M to something smaller?

Yes, if I reduce the spiffs partition to 2M, when I run the command to write in the encrypted partition, the device prints this error:

Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x40194018: ddae0403 3ed4af8f f01d0070
0x40194018: lwip_standard_chksum at /home/baintex/esp/esp-idf/components/lwip/lwip/src/core/inet_chksum.c:173

Core 0 register dump:
PC : 0x4019401c PS : 0x00060630 A0 : 0x8008ac3c A1 : 0x3ffbd610
0x4019401c: esp_pm_impl_waiti at /home/baintex/esp/esp-idf/components/esp32/pm_esp32.c:471

A2 : 0x00000008 A3 : 0x00000000 A4 : 0x00000001 A5 : 0x3ffbce10
A6 : 0x00000003 A7 : 0x00060423 A8 : 0x800d602d A9 : 0x3ffb3c40
A10 : 0x00000000 A11 : 0x00000001 A12 : 0x00000001 A13 : 0x80000001
A14 : 0x000000fe A15 : 0x00000001 SAR : 0x00000000 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000

Backtrace:0x40194019:0x3ffbd610 0x4008ac39:0x3ffbd630 0x4008a28d:0x3ffbd650
0x40194019: lwip_standard_chksum at ??:?

0x4008ac39: prvIdleTask at /home/baintex/esp/esp-idf/components/freertos/tasks.c:3385 (discriminator 1)

0x4008a28d: vPortTaskWrapper at /home/baintex/esp/esp-idf/components/freertos/xtensa/port.c:143

ELF file SHA256: 0e1658ed6ead31f5

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4
load:0x3fff0034,len:9536
ho 0 tail 12 room 4
load:0x40078000,len:17628
load:0x40080400,len:5144
0x40080400: _init at ??:?

entry 0x40080704

@mahavirj
Copy link
Member

mahavirj commented Jan 6, 2021

@jarcos-al Can you please try https://github.com/espressif/esp-idf/tree/master/examples/security/flash_encryption at your end once and see if it works as expected? We haven't been successful in reproducing this problem so far.

@jarcos-al
Copy link
Author

Yes, the example works fine.
I tried once time again to run in my proyect and now, the console print this:
E (50807) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (50807) task_wdt: - IDLE1 (CPU 1)
E (50807) task_wdt: Tasks currently running:
E (50807) task_wdt: CPU 0: IDLE0
E (50807) task_wdt: CPU 1: console_repl
E (50807) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x400D7A60:0x3FFB0770 0x40084CFD:0x3FFB0790 0x4019E09B:0x3FFBE170 0x400D7D72:0x3FFBE190 0x4008EB91:0x3FFBE1B0 0x4008E171:0x3FFBE1D0
0x400d7a60: task_wdt_isr at C:/esp/esp-idf/components/esp_common/src/task_wdt.c:187

0x40084cfd: _xt_lowint1 at C:/esp/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1105

0x4019e09b: esp_pm_impl_waiti at C:/esp/esp-idf/components/esp32/pm_esp32.c:484

0x400d7d72: esp_vApplicationIdleHook at C:/esp/esp-idf/components/esp_common/src/freertos_hooks.c:63

0x4008eb91: prvIdleTask at C:/esp/esp-idf/components/freertos/tasks.c:3385 (discriminator 1)

0x4008e171: vPortTaskWrapper at C:/esp/esp-idf/components/freertos/xtensa/port.c:143

E (50807) task_wdt: Print CPU 1 backtrace

Backtrace:0x40082102:0x3FFB0D70 0x40084CFD:0x3FFB0D90 0x40062252:0x3FFDD4C0 0x4009DF4B:0x3FFDD4E0 0x4009DF86:0x3FFDD510 0x4009E139:0x3FFDD540 0x4009E1D6:0x3FFD
D560 0x40085E1C:0x3FFDD590 0x40085D5D:0x3FFDD5D0 0x4010077F:0x3FFDD5F0 0x400DA071:0x3FFDD610 0x4008954F:0x3FFDD630 0x400D8E11:0x3FFDD670 0x400FC21D:0x3FFDD7B0
0x400FC2A2:0x3FFDD7D0 0x4008E171:0x3FFDD800
0x40082102: esp_crosscore_isr at C:/esp/esp-idf/components/esp32/crosscore_int.c:80

0x40084cfd: _xt_lowint1 at C:/esp/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1105

0x4009df4b: esp_rom_spiflash_read_status at C:/esp/esp-idf/components/spi_flash/esp32/spi_flash_rom_patch.c:215

0x4009df86: esp_rom_spiflash_wait_idle at C:/esp/esp-idf/components/spi_flash/esp32/spi_flash_rom_patch.c:42

0x4009e139: esp_rom_spiflash_write_status at C:/esp/esp-idf/components/spi_flash/esp32/spi_flash_rom_patch.c:234

0x4009e1d6: esp_rom_spiflash_unlock at C:/esp/esp-idf/components/spi_flash/esp32/spi_flash_rom_patch.c:82

0x40085e1c: spi_flash_write_encrypted_chip at C:/esp/esp-idf/components/spi_flash/esp32/flash_ops_esp32.c:43

0x40085d5d: spi_flash_write_encrypted at C:/esp/esp-idf/components/spi_flash/flash_ops.c:473

0x4010077f: esp_partition_write at C:/esp/esp-idf/components/spi_flash/partition.c:398

0x400da071: writeESP32partition at C:\sentio\ESP32_MiniHUB\build/../main/drv/NVS/NVS_driver.c:39

0x4008954f: NVS_write_partition at C:\sentio\ESP32_MiniHUB\build/../main/drv/NVS/NVS_driver.c:128

0x400d8e11: set_credentials at C:\sentio\ESP32_MiniHUB\build/../main/drv/Console/MiniHub_Console.c:271

0x400fc21d: esp_console_run at C:/esp/esp-idf/components/console/commands.c:215

0x400fc2a2: esp_console_repl_thread at C:/esp/esp-idf/components/console/esp_console_repl.c:83

0x4008e171: vPortTaskWrapper at C:/esp/esp-idf/components/freertos/xtensa/port.c:143

@jarcos-al
Copy link
Author

@mahavirj , I have found the problem. I have unchecked "Support for SPI-connected RAM" option, and the code works fine. I do not know the reason for this failure

@mahavirj
Copy link
Member

mahavirj commented Jan 8, 2021

@jarcos-al

E (50807) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:

(As I had mentioned in my previous reply) This error indicates problem with tasks running for prolonged time without yielding (e.g. some task running with tight loop).

Please refer to documentation available at https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/wdts.html#task-watchdog-timer. You may try with larger timeout value for this timer (default is 5sec) or disable this configuration option for testing purpose.

I have unchecked "Support for SPI-connected RAM" option, and the code works fine

Do you see similar problem if you keep this configuration enabled in https://github.com/espressif/esp-idf/tree/master/examples/security/flash_encryption example? Can you please modify this example such that it can reproduce problem you are seeing?

@jarcos-al
Copy link
Author

@jarcos-al

E (50807) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:

(As I had mentioned in my previous reply) This error indicates problem with tasks running for prolonged time without yielding (e.g. some task running with tight loop).

Please refer to documentation available at https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/wdts.html#task-watchdog-timer. You may try with larger timeout value for this timer (default is 5sec) or disable this configuration option for testing purpose.

I have unchecked "Support for SPI-connected RAM" option, and the code works fine

Do you see similar problem if you keep this configuration enabled in https://github.com/espressif/esp-idf/tree/master/examples/security/flash_encryption example? Can you please modify this example such that it can reproduce problem you are seeing?

After checking all the settings of the sdkconfig, comparing with the example project, I have verified that what produces the error is the option "Flash SPI speed = 80 MHz" in "Serial flasher config" together with the option "Support for external, SPI -RAM connected ". With these two options set in the example https://github.com/espressif/esp-idf/tree/master/examples/security/flash_encryption, the same error is reproduced.
I have fixed this error by changing the "Flash SPI speed" to 40MHz.

@negativekelvin
Copy link
Contributor

#6322

@mahavirj
Copy link
Member

mahavirj commented Jan 12, 2021

@jarcos-al Thank you for sharing latest findings. I can reproduce this issue locally now, will keep you posted about updates.

@mythbuster5
Copy link
Collaborator

A quick fix I don't know whether can help you.

in the file esp_flash_api.c, add header #include "../cache_utils.h"

And then, replace the code

//currently the legacy implementation is used, from flash_ops.c
esp_err_t spi_flash_write_encrypted(size_t dest_addr, const void *src, size_t size);

esp_err_t IRAM_ATTR esp_flash_write_encrypted(esp_flash_t *chip, uint32_t address, const void *buffer, uint32_t length)
{
    /*
     * Since currently this feature is supported only by the hardware, there
     * is no way to support non-standard chips. We use the legacy
     * implementation and skip the chip and driver layers.
     */
    esp_err_t err = rom_spiflash_api_funcs->chip_check(&chip);
    if (err != ESP_OK) return err;
    if (buffer == NULL || address > chip->size || address+length > chip->size) {
        return ESP_ERR_INVALID_ARG;
    }
    return spi_flash_write_encrypted(address, buffer, length);
}

inline static IRAM_ATTR bool regions_overlap(uint32_t a_start, uint32_t a_len,uint32_t b_start, uint32_t b_len)
{
    uint32_t a_end = a_start + a_len;
    uint32_t b_end = b_start + b_len;
    return (a_end > b_start && b_end > a_start);
}

//currently the legacy implementation is used, from flash_ops.c
esp_err_t spi_flash_read_encrypted(size_t src, void *dstv, size_t size);

esp_err_t IRAM_ATTR esp_flash_read_encrypted(esp_flash_t *chip, uint32_t address, void *out_buffer, uint32_t length)
{
    /*
     * Since currently this feature is supported only by the hardware, there
     * is no way to support non-standard chips. We use the legacy
     * implementation and skip the chip and driver layers.
     */
    esp_err_t err = rom_spiflash_api_funcs->chip_check(&chip);
    if (err != ESP_OK) return err;
    return spi_flash_read_encrypted(address, out_buffer, length);
}

with

extern void spi_common_set_dummy_output(esp_rom_spiflash_read_mode_t mode);
extern void spi_dummy_len_fix(uint8_t spi, uint8_t freqdiv);
static void IRAM_ATTR fix_rom_func(void)
{
    esp_rom_spiflash_read_mode_t read_mode;
    uint8_t freqdiv;
#  if defined CONFIG_ESPTOOLPY_FLASHMODE_QIO
    read_mode = ESP_ROM_SPIFLASH_QIO_MODE;
#  elif defined CONFIG_ESPTOOLPY_FLASHMODE_QOUT
    read_mode = ESP_ROM_SPIFLASH_QOUT_MODE;
#  elif defined CONFIG_ESPTOOLPY_FLASHMODE_DIO
    read_mode = ESP_ROM_SPIFLASH_DIO_MODE;
#  elif defined CONFIG_ESPTOOLPY_FLASHMODE_DOUT
    read_mode = ESP_ROM_SPIFLASH_DOUT_MODE;
#  endif

#  if defined CONFIG_ESPTOOLPY_FLASHFREQ_80M
    freqdiv = 1;
#  elif defined CONFIG_ESPTOOLPY_FLASHFREQ_40M
    freqdiv = 2;
#  elif defined CONFIG_ESPTOOLPY_FLASHFREQ_26M
    freqdiv = 3;
#  elif defined CONFIG_ESPTOOLPY_FLASHFREQ_20M
    freqdiv = 4;
#endif

    spi_flash_disable_interrupts_caches_and_other_cpu();
    esp_rom_spiflash_config_clk(freqdiv, 1);
#if !CONFIG_IDF_TARGET_ESP32
    spi_dummy_len_fix(1, freqdiv);
#endif
    esp_rom_spiflash_config_readmode(read_mode);
#if CONFIG_IDF_TARGET_ESP32S3 || CONFIG_IDF_TARGET_ESP32C3
    spi_common_set_dummy_output(read_mode);
#endif
    spi_flash_enable_interrupts_caches_and_other_cpu();
}

//currently the legacy implementation is used, from flash_ops.c
esp_err_t spi_flash_write_encrypted(size_t dest_addr, const void *src, size_t size);

esp_err_t IRAM_ATTR esp_flash_write_encrypted(esp_flash_t *chip, uint32_t address, const void *buffer, uint32_t length)
{
    /*
     * Since currently this feature is supported only by the hardware, there
     * is no way to support non-standard chips. We use the legacy
     * implementation and skip the chip and driver layers.
     */
    esp_err_t err = rom_spiflash_api_funcs->chip_check(&chip);
    if (err != ESP_OK) return err;
    if (buffer == NULL || address > chip->size || address+length > chip->size) {
        return ESP_ERR_INVALID_ARG;
    }
    fix_rom_func();
    return spi_flash_write_encrypted(address, buffer, length);
}

inline static IRAM_ATTR bool regions_overlap(uint32_t a_start, uint32_t a_len,uint32_t b_start, uint32_t b_len)
{
    uint32_t a_end = a_start + a_len;
    uint32_t b_end = b_start + b_len;
    return (a_end > b_start && b_end > a_start);
}

//currently the legacy implementation is used, from flash_ops.c
esp_err_t spi_flash_read_encrypted(size_t src, void *dstv, size_t size);

esp_err_t IRAM_ATTR esp_flash_read_encrypted(esp_flash_t *chip, uint32_t address, void *out_buffer, uint32_t length)
{
    /*
     * Since currently this feature is supported only by the hardware, there
     * is no way to support non-standard chips. We use the legacy
     * implementation and skip the chip and driver layers.
     */
    esp_err_t err = rom_spiflash_api_funcs->chip_check(&chip);
    if (err != ESP_OK) return err;
    fix_rom_func();
    return spi_flash_read_encrypted(address, out_buffer, length);
}

@mythbuster5
Copy link
Collaborator

Sorry for the long wait, I have fixed the issue(flash_encryption failed with 80M flash and 40M psram) with the patch below, could you please have a try? Thanks!

esp32_patch_for_flash_encryption_with_40Mram_80Mflash.txt

@jarcos-al
Copy link
Author

Sorry for the long wait, I have fixed the issue(flash_encryption failed with 80M flash and 40M psram) with the patch below, could you please have a try? Thanks!

esp32_patch_for_flash_encryption_with_40Mram_80Mflash.txt

Ok, I have downloaded this patch but git repport a problem with it.
"error: corrupt patch at line 22"

@mythbuster5
Copy link
Collaborator

Sorry for the long wait, I have fixed the issue(flash_encryption failed with 80M flash and 40M psram) with the patch below, could you please have a try? Thanks!
esp32_patch_for_flash_encryption_with_40Mram_80Mflash.txt

Ok, I have downloaded this patch but git repport a problem with it.
"error: corrupt patch at line 22"

Hoo, maybe I ignore something, could you please try to fix it manually with what the patch shows now?🙂 I will upload a new patch tomorrow.

projectgus pushed a commit that referenced this issue Feb 10, 2021
0xFEEDC0DE64 added a commit to 0xFEEDC0DE64/esp-idf that referenced this issue Feb 18, 2021
0xFEEDC0DE64 added a commit to 0xFEEDC0DE64/esp-idf that referenced this issue Feb 18, 2021
espressif-bot pushed a commit that referenced this issue Mar 20, 2021
espressif-bot pushed a commit that referenced this issue Mar 24, 2021
@ginkgm
Copy link
Collaborator

ginkgm commented Apr 6, 2021

Hi @jarcos-al ,

We have provided the patch of this issue , could you please have a try? I saw you have some work based on it, do you have any trouble using it?

Michael

@espressif-bot espressif-bot added the Awaiting Response awaiting a response from the author label Apr 6, 2021
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Done Issue is done internally labels Apr 26, 2021
@Alvin1Zhang
Copy link
Collaborator

Thanks for reporting and sharing updates, feel free to reopen.

espressif-bot pushed a commit that referenced this issue Sep 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

7 participants