Hi,

We're using Node.js and the Mocha test framework to run automated tests on our ESP32-based device. This has been working well, including using BLE with "web-bluetooth" and serial port access with the "serialport" package.

We want to install factory firmware and carry out other actions such as ...

We write log messages to the UART debug output using ESP_LOGI, etc.

In a recent build, I have noticed that 1 or 2 characters are occasionally lost from my debug log messages. It is somewhat random but generally happens when the CPU is quite busy. Missing characters are usually near the end of a log ...

This is a bit late, but for anyone who finds this... I ran into the same issue using ESP-IDF v5.5.1

Secure Boot V2 is only supported on chip revisions 3.0 or later. To allow you to select secure boot V2, you also have to go to:

(Top) → Component config → Hardware Settings → Chip revision → Minimum ...

Thanks, I think I confused myself. Are you saying that the "read-flash" esptool command bypasses the hardware decryption completely? I suppose if it didn't, it would do the opposite of this (i.e. decrypt the encrypted data and also turn the empty data into gibberish...).

Hi,

We have a device using ESP32. We have turned on secure boot V2 and flash encryption with a device-generated flash encryption key. For development, we use flash encryption in "development" mode so we can re-flash easily, although for production we enable "production" mode to lock it down.

I ...

We are migrating an older product from ESP-IDF v4.4.4 to v5.4.2

We have an OTA update process which uses BLE to receive update files. The data is received and written to flash in 8 KiB chunks, using the esp_ota_write function. We are using secure boot (v2) and flash encryption, and the encryption ...

I'm using the MCPWM input capture to time the rising edges of a signal:


ESP_ERROR_CHECK(
mcpwm_new_capture_timer(
&(mcpwm_capture_timer_config_t)
{
.clk_src = MCPWM_CAPTURE_CLK_SRC_DEFAULT, // All input capture operations use the APB clock (80 MHz)
.group_id = 0,
},
&m_mcpwm_cap_timer ...

CPU reset does not affect GPIOs. See TRM 3.1.1.

Thanks - I think it's TRM section 4.1.1? (System Reset). I had missed that bit.

You may want to look into gpio_hold_en() &c. to make sure nothing messes with your desired pin state.

Interesting - thanks!

Any chance you can share a snippet of your bootloader hook?


Here's my bootloader hook to set GPIO 21 high at boot time.


// Base address of GPIO registers:
#define GPIO_REG_BASE_ADDR 0x3FF44000

// GPIO Output Register Offsets:
#define GPIO_OUT_REG (GPIO_REG_BASE_ADDR + 0x04) // Write GPIO ...