ESP-IDF is the development framework for Espressif SoCs supported on Windows, Linux and macOS.

Espressif Systems

Last update: Jan 4, 2023

Related tags

Networking and Internet esp-idf

Overview

Espressif IoT Development Framework

中文版

ESP-IDF is the development framework for Espressif SoCs supported on Windows, Linux and macOS.

ESP-IDF Release and SoC Compatibility

The following table shows ESP-IDF support of Espressif SoCs where and denote preview status and support, respectively. In preview status the build is not yet enabled and some crucial parts could be missing (like documentation, datasheet). Please use an ESP-IDF release where the desired SoC is already supported.

Chip	v3.3	v4.0	v4.1	v4.2	v4.3	v4.4
ESP32
ESP32-S2
ESP32-C3
ESP32-S3							Announcement
ESP32-H2							Announcement

Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by RTOS SDK instead.

Developing With ESP-IDF

Setting Up ESP-IDF

See https://idf.espressif.com/ for links to detailed instructions on how to set up the ESP-IDF depending on chip you use.

Note: Each SoC series and each ESP-IDF release has its own documentation. Please see Section Versions on how to find documentation and how to checkout specific release of ESP-IDF.

Non-GitHub forks

ESP-IDF uses relative locations as its submodules URLs (.gitmodules). So they link to GitHub. If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script tools/set-submodules-to-github.sh after git clone. The script sets absolute URLs for all submodules, allowing git submodule update --init --recursive to complete. If cloning ESP-IDF from GitHub, this step is not needed.

Finding a Project

As well as the esp-idf-template project mentioned in Getting Started, ESP-IDF comes with some example projects in the examples directory.

Once you've found the project you want to work with, change to its directory and you can configure and build it.

To start your own project based on an example, copy the example project directory outside of the ESP-IDF directory.

Quick Reference

See the Getting Started guide links above for a detailed setup guide. This is a quick reference for common commands when working with ESP-IDF projects:

Setup Build Environment

(See the Getting Started guide listed above for a full list of required steps with more details.)

Install host build dependencies mentioned in the Getting Started guide.
Run the install script to set up the build environment. The options include install.bat or install.ps1 for Windows, and install.sh or install.fish for Unix shells.
Run the export script on Windows (export.bat) or source it on Unix (source export.sh) in every shell environment before using ESP-IDF.

Configuring the Project

idf.py set-target sets the target of the project to . Run idf.py set-target without any arguments to see a list of supported targets.
idf.py menuconfig opens a text-based configuration menu where you can configure the project.

Compiling the Project

idf.py build

... will compile app, bootloader and generate a partition table based on the config.

Flashing the Project

When the build finishes, it will print a command line to use esptool.py to flash the chip. However you can also do this automatically by running:

idf.py -p PORT flash

Replace PORT with the name of your serial port (like COM3 on Windows, /dev/ttyUSB0 on Linux, or /dev/cu.usbserial-X on MacOS. If the -p option is left out, idf.py flash will try to flash the first available serial port.

This will flash the entire project (app, bootloader and partition table) to a new chip. The settings for serial port flashing can be configured with idf.py menuconfig.

You don't need to run idf.py build before running idf.py flash, idf.py flash will automatically rebuild anything which needs it.

Viewing Serial Output

The idf.py monitor target uses the idf_monitor tool to display serial output from Espressif SoCs. idf_monitor also has a range of features to decode crash output and interact with the device. Check the documentation page for details.

Exit the monitor by typing Ctrl-].

To build, flash and monitor output in one pass, you can run:

idf.py flash monitor

Compiling & Flashing Only the App

After the initial flash, you may just want to build and flash just your app, not the bootloader and partition table:

idf.py app - build just the app.
idf.py app-flash - flash just the app.

idf.py app-flash will automatically rebuild the app if any source files have changed.

(In normal development there's no downside to reflashing the bootloader and partition table each time, if they haven't changed.)

Erasing Flash

The idf.py flash target does not erase the entire flash contents. However it is sometimes useful to set the device back to a totally erased state, particularly when making partition table changes or OTA app updates. To erase the entire flash, run idf.py erase-flash.

This can be combined with other targets, ie idf.py -p PORT erase-flash flash will erase everything and then re-flash the new app, bootloader and partition table.

Resources

Documentation for the latest version: https://docs.espressif.com/projects/esp-idf/. This documentation is built from the docs directory of this repository.
The esp32.com forum is a place to ask questions and find community resources.
Check the Issues section on github if you find a bug or have a feature request. Please check existing Issues before opening a new one.
If you're interested in contributing to ESP-IDF, please check the Contributions Guide.

Comments

Bricked ESP32 Modules - XMC flash chip corrupt (IDFGH-6332)
Environment

Module or chip used: ESP32-WROVER-E (16M)

IDF version: 3.3.5

Build System: Make

Compiler version: 1.22.0-97-gc752ad5d

Operating System: Windows

(Windows only) environment type: MSYS2 mingw32

Power Supply: external 3.3V

Chip is ESP32-D0WD-V3 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e0:e2:e6:4b:be:f8

Problem Description

We've recently gotten at least 3 bricked devices returned from customers with exactly the same symptoms. ESP module does not boot from flash. It seems to be a failure of the first-stage bootloader.

This was reported a few months ago on esp32.com but didn't get any attention from Espressif. I then filled-out the form here a couple weeks ago: But I didn't even get an email confirmation that it was received.

WiFive pointed out that the garbage load address 0xff001cff looks like a left-shifted version of the correct 0x3fff001c

Steps to reproduce

I'm unable to reproduce the issue in the lab. It has occurred in a small percentage ( ~ 0.1%) of units which have been sold and used by customers for up to 3 years.

Code to reproduce this issue

My application is based on this project, which includes a OTA update mechanism.

Debug Logs

ets Jul 29 2019 12:21:46 rst:0x10 (RTCWDT_RTC_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:0x3fff0018,len:4 load:0xff001cff,len:1809471 1150 mmu set 00010000, pos 00010000 1150 mmu set 00020000, pos 00020000 1150 mmu set 00030000, pos 00030000 1150 mmu set 00040000, pos 00040000 1150 mmu set 00050000, pos 00050000 1150 mmu set 00060000, pos 00060000 1150 mmu set 00070000, pos 00070000 1150 mmu set 00080000, pos 00080000 1150 mmu set 00090000, pos 00090000 1150 mmu set 000a0000, pos 000a0000 1150 mmu set 000b0000, pos 000b0000 1150 mmu set 000c0000, pos 000c0000 1150 mmu set 000d0000, pos 000d0000 1150 mmu set 000e0000, pos 000e0000 ets Jul 29 2019 12:21:46 rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) waiting for download

Other items

sdkconfig.txt
Awaiting Response Status: Done Resolution: Done
opened by phatpaul 99
MODBUS Serial example not working (IDFGH-5822)

Hi newbie here, working with esp-idf 4.2.2

I am working on MODBUS Serial example of esp-idf,I simply just connected the hardware as shown in the example.

ESP32-1(Master) and ESP32-2(Slave) by using two TTL to RS485 converters.

But I am not able to get the expected output. I am gettinfg the 0x108 Err that is invalid slave response.

Master output: E (65579) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65579) MASTER_TEST: Characteristic #0 (Data_channel_0) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). E (65599) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65609) MASTER_TEST: Characteristic #1 (Humidity_1) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). E (65619) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65629) MASTER_TEST: Characteristic #2 (Temperature_1) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). E (65649) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65649) MASTER_TEST: Characteristic #3 (Humidity_2) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). E (65669) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65679) MASTER_TEST: Characteristic #4 (Temperature_2) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). E (65699) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65699) MASTER_TEST: Characteristic #5 (Humidity_3) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). E (65719) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x108) (ESP_ERR_INVALID_RESPONSE). E (65729) MASTER_TEST: Characteristic #6 (Test_regs) read fail, err = 0x108 (ESP_ERR_INVALID_RESPONSE). I (65739) MASTER_TEST: Characteristic #7 RelayP1 (on/off) value = OFF (0x55) read successful. I (65749) MASTER_TEST: Characteristic #8 RelayP2 (on/off) value = OFF (0xaa) read successful. E (67749) MASTER_TEST: Alarm is not triggered after 30 retries. I (67749) MASTER_TEST: Destroy master...

Slave Response: [0;32mI (97984) SLAVE_TEST: COILS READ (97681730 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (97994) SLAVE_TEST: COILS READ (97690818 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (100154) SLAVE_TEST: COILS READ (99851729 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (100164) SLAVE_TEST: COILS READ (99860956 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (102324) SLAVE_TEST: COILS READ (102021659 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (102334) SLAVE_TEST: COILS READ (102030886 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (104494) SLAVE_TEST: COILS READ (104191526 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (104504) SLAVE_TEST: COILS READ (104200746 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (106664) SLAVE_TEST: COILS READ (106361451 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (106674) SLAVE_TEST: COILS READ (106370676 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (108834) SLAVE_TEST: COILS READ (108532558 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (108844) SLAVE_TEST: COILS READ (108541925 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (111004) SLAVE_TEST: COILS READ (110702488 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (111014) SLAVE_TEST: COILS READ (110711785 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (113174) SLAVE_TEST: COILS READ (112872418 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (113184) SLAVE_TEST: COILS READ (112881716 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (115344) SLAVE_TEST: COILS READ (115042417 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (115354) SLAVE_TEST: COILS READ (115051715 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (117514) SLAVE_TEST: COILS READ (117212208 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (117524) SLAVE_TEST: COILS READ (117221581 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (119684) SLAVE_TEST: COILS READ (119382138 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (119694) SLAVE_TEST: COILS READ (119391435 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (121854) SLAVE_TEST: COILS READ (121552068 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (121864) SLAVE_TEST: COILS READ (121561365 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (124024) SLAVE_TEST: COILS READ (123722067 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (124034) SLAVE_TEST: COILS READ (123731364 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (126194) SLAVE_TEST: COILS READ (125891858 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (126204) SLAVE_TEST: COILS READ (125901224 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (128364) SLAVE_TEST: COILS READ (128061788 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (128374) SLAVE_TEST: COILS READ (128071085 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (130534) SLAVE_TEST: COILS READ (130231718 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (130544) SLAVE_TEST: COILS READ (130241014 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (132704) SLAVE_TEST: COILS READ (132401717 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (132714) SLAVE_TEST: COILS READ (132411014 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (134874) SLAVE_TEST: COILS READ (134571511 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (134884) SLAVE_TEST: COILS READ (134580874 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (137044) SLAVE_TEST: COILS READ (136741438 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (137054) SLAVE_TEST: COILS READ (136750734 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (139214) SLAVE_TEST: COILS READ (138911367 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (139224) SLAVE_TEST: COILS READ (138920664 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (141384) SLAVE_TEST: COILS READ (141081367 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (141394) SLAVE_TEST: COILS READ (141090663 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (143554) SLAVE_TEST: COILS READ (143251158 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (143564) SLAVE_TEST: COILS READ (143260524 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (145724) SLAVE_TEST: COILS READ (145421087 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (145734) SLAVE_TEST: COILS READ (145430384 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (147894) SLAVE_TEST: COILS READ (147591017 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (147904) SLAVE_TEST: COILS READ (147600314 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (150064) SLAVE_TEST: COILS READ (149761016 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (150074) SLAVE_TEST: COILS READ (149770313 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (152234) SLAVE_TEST: COILS READ (151930807 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (152244) SLAVE_TEST: COILS READ (151940174 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (154404) SLAVE_TEST: COILS READ (154100737 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (154414) SLAVE_TEST: COILS READ (154110034 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (156574) SLAVE_TEST: COILS READ (156270667 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (156584) SLAVE_TEST: COILS READ (156279964 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (158744) SLAVE_TEST: COILS READ (158440666 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (158754) SLAVE_TEST: COILS READ (158449963 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (160914) SLAVE_TEST: COILS READ (160610527 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (160924) SLAVE_TEST: COILS READ (160619893 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m [0;32mI (163084) SLAVE_TEST: COILS READ (162780387 us), ADDR:0, TYPE:32, INST_ADDR:0x3ffb26a4, SIZE:8[0m [0;32mI (163094) SLAVE_TEST: COILS READ (162789685 us), ADDR:8, TYPE:32, INST_ADDR:0x3ffb26a5, SIZE:8[0m ![processed](https://user-images.githubusercontent.com/46959108/132165759-24327fb1-46d1-4ec9-89d4-218db4b1ed43.jpeg)

Please help to solve this issue.

Thank you in advance.
Awaiting Response Status: Done Resolution: Done

opened by rjrajbir 87
Wifi - meaning of log message (IDFGH-1299)

Sorry for the cross-post - I just remembered that I was told to post issues here instead on the sub projects as they are less monitored. I'll close the other issue.

I'm trying to figure out why the wifi driver is running out of memory, when there is 4MB free:

W (115021) wifi: alloc eb len=24 type=3 fail, heap:4098144

I can't find where this is logged so I assume that it is part of the still closed-source libraries(?)

What does type=3 mean in this case and what other possible values are there? Desired type DRAM/IRAM or memory capability?

opened by PerMalmberg 87

[TW#17765] I2C crashing - watchdog timeout (master & v3.0 branch)

I have a project that has three I2C slave devices on a single bus (running at 100kHz). For some time I was developing with ESP-IDF 2.1.1 and everything was working pretty well, except for a weird problem where the I2C master would freeze up after a few minutes. I did some research and it looks like this is a problem with the I2C master hardware state machine which has been addressed in more recent commits of ESP-IDF. So to make use of this fix I migrated my project to use master (595688a32ad653d8e6cb1c7682b813f96125853e). I had to make a few changes (remove references to FreeRTOS heap measurement commands, add nvs_flash_init() before initialising WiFi) but then everything seemed to work well. The slave devices are all being polled correctly and everything seems happy.

The project is here: https://github.com/DavidAntliff/esp32-poolmon/tree/ESP-IDF_master

I came back a little while later and the application is crashing over and over with the following console output shortly after boot:

Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Register dump:
PC      : 0x400859f3  PS      : 0x00060034  A0      : 0x80084685  A1      : 0x3ffb0590  
0x400859f3: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-master/components/freertos/./queue.c:2037

A2      : 0x00000001  A3      : 0x00000000  A4      : 0x3ffb05b0  A5      : 0x00000002  
A6      : 0x3ffbc970  A7      : 0x00060021  A8      : 0x800859f3  A9      : 0x3ffb0570  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x00000002  A13     : 0x3ffbadc0  
A14     : 0x00000000  A15     : 0x400849fc  SAR     : 0x00000012  EXCCAUSE: 0x00000005  
0x400849fc: i2c_isr_handler_default at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023

EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x400859f3:0x3ffb0590 0x40084682:0x3ffb05b0 0x40084a89:0x3ffb05e0 0x40082ba5:0x3ffb0610 0x4000bfed:0x00000000
0x400859f3: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-master/components/freertos/./queue.c:2037

0x40084682: i2c_master_cmd_begin_static at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023

0x40084a89: i2c_isr_handler_default at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023

0x40082ba5: _xt_lowint1 at /Users/david/esp32/esp-idf-master/components/freertos/./xtensa_vectors.S:1105

Rebooting...

A software or on-board reset does not stop this endless reset behaviour, however removing power for a short period of time does "fix" the issue. It is strange that a brief ESP32 reset does not clear it. (EDIT: but a long reset press does).

opened by DavidAntliff 78

[TW#13919] Bluetooth HID implementation progress? (IDFGH-6354)

Hi all,

I'm considering to build a bluetooth keyboard by myself later on with ESP32 as its microcontroller. But I can't find much details or documentations about those HID APIs. I did found a topic on Espressif forum saying "will implement it eventually". So...did you finish implementing those stuff?

Regards, Jackson
Status: Done Resolution: Done

opened by huming2207 71

flash read err, 1000 (IDFGH-807)

Hi,

I see the above message on average 5 out of 6 times when resetting ESP32 DevKitJ board The whole log with this message looks like below (02_blink example loaded):

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0x3ffc0008,len:1964
load:0x40078000,len:3648
ho 0 tail 12 room 4
load:0x40080000,len:256
entry 0x40080034
I (305) heap_alloc_caps: Initializing heap allocator:
I (306) heap_alloc_caps: Region 19: 3FFB1B9C len 0002E464 tag 0
I (307) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (317) cpu_start: Pro cpu up.
I (323) cpu_start: Single core mode
I (329) cpu_start: Pro cpu start user code
rtc v118 Oct 19 2016 15:22:11
XTAL 40M
I (368) cpu_start: Starting scheduler on PRO CPU.

The log without message looks as follows:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0x3ffc0008,len:1964
load:0x40078000,len:3648
ho 0 tail 12 room 4
load:0x40080000,len:256
entry 0x40080034
I (305) heap_alloc_caps: Initializing heap allocator:
I (306) heap_alloc_caps: Region 19: 3FFB1B9C len 0002E464 tag 0
I (307) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (317) cpu_start: Pro cpu up.
I (323) cpu_start: Single core mode
I (329) cpu_start: Pro cpu start user code
rtc v118 Oct 19 2016 15:22:11
XTAL 40M
I (368) cpu_start: Starting scheduler on PRO CPU.

Observations:

Massage flash read err, 1000 shows up as well when I erase_flash using esptool.py.
There seem to be no issues with esp-idf examples running on this board (except the message on start up)
Message show up for all examples I tried
I do not see this message on two other boards I have; ESP32 Demo Board V2 and Core Board V2 (aka DevKitC)

Do you think I can troubleshoot something about it?

opened by krzychb 68

Trouble with PPPoS client - Address of function esp_handle_uart_data() become null (in esp_modem.c) (IDFGH-4162)

Environment

Development Kit: none
Module or chip used: ESP32-WROOM-32
IDF version: v4.1
Build System: PlatformIO (2.0.0+sha.3688b7b)
Operating System: macOS
Using an IDE?: VSCode with PlatformIO
Power Supply: USB or external 5V

Problem Description

In the example of PPPoS (client), there is something troubles and the application crash with a Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited). Exception was unhandled. The message is:

Guru Meditation Error: Core  0 panic'ed (InstrFetchProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x00000000  PS      : 0x00060a30  A0      : 0x800d56de  A1      : 0x3ffbccb0  
A2      : 0x3ffbb428  A3      : 0x00000000  A4      : 0x3ffbb98c  A5      : 0x00000000  
A6      : 0x3ffbb9cc  A7      : 0x00000000  A8      : 0x800d5584  A9      : 0x3ffbcc60  
A10     : 0x3ffbb46c  A11     : 0x00000009  A12     : 0x00000000  A13     : 0x00000000  
A14     : 0x3ffbb670  A15     : 0x00000009  SAR     : 0x00000004  EXCCAUSE: 0x00000014  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

ELF file SHA256: e3e23c687850dc53

Backtrace: 0xfffffffd:0x3ffbccb0 |<-CORRUPTED

After multiple debugs with JTAG (ESP-Prog) and debug messages, I have found where the trouble is. The application crash in the method esp_handle_uart_data in esp_modem.c file. To debug the trouble, I have created a specific repository (https://github.com/jonathandreyer/esp32-sim7000) with the code which exposes the trouble. With this code, the debug log is:

D (7516) sim800: STATUS of module is OK
D (7516) pppos-example: Device SIM800 is power_up()
D (7516) sim800: start opening of SIM800 module
D (7516) sim800: try to sync with the module
D (7526) esp-modem: modem>>: DST: 0

E (7526) esp-modem: esp_dte_handle_line(90): no handler for line
W (7526) pppos-example: Unknow line received: DST: 0

D (7636) esp-modem: modem>>: *PSUTTZ: 20/10/25,21:41:30","+04",0

E (7636) esp-modem: esp_dte_handle_line(90): no handler for line
W (7636) pppos-example: Unknow line received: *PSUTTZ: 20/10/25,21:41:30","+04",0

D (8516) sim800: .
D (8516) esp-modem: modem<<: AT
D (8516) esp-modem: handle_uart_data #1, len 3
I (8516) esp-modem: 0x3ffbb46c   41 54 0d                                          |AT.|
D (8516) esp-modem: handle_uart_data #2, callback method is NULL
assertion "esp_dte->receive_cb" failed: file "components/modem/esp_modem.c", line 152, function: esp_handle_uart_data
abort() was called at PC 0x40119e57 on core 0

ELF file SHA256: 74d46404e09b68da

Backtrace: 0x400841e1:0x3ffbcc40 0x40084575:0x3ffbcc60 0x40119e57:0x3ffbcc80 0x400d565e:0x3ffbccb0 0x400d57fb:0x3ffbcce0 0x40085a41:0x3ffbcd10
  #0  0x400841e1:0x3ffbcc40 in invoke_abort at /Users/<USER>/.platformio/packages/framework-espidf/components/esp32/panic.c:157
  #1  0x40084575:0x3ffbcc60 in abort at /Users/<USER>/.platformio/packages/framework-espidf/components/esp32/panic.c:174
  #2  0x40119e57:0x3ffbcc80 in __assert_func at /builds/idf/crosstool-NG/.build/HOST-x86_64-apple-darwin12/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)
  #3  0x400d565e:0x3ffbccb0 in esp_handle_uart_data at components/modem/esp_modem.c:152 (discriminator 1)
  #4  0x400d57fb:0x3ffbcce0 in uart_event_task_entry at components/modem/esp_modem.c:172
  #5  0x40085a41:0x3ffbcd10 in vPortTaskWrapper at /Users/<USER>/.platformio/packages/framework-espidf/components/freertos/port.c:143

Expected Behavior

Actual Behavior

Steps to reproduce

In this case, I use a SIM7000E but it will probably work with SIM800 or another module.

Code to reproduce this issue

The code to reproduce this trouble is available here: https://github.com/jonathandreyer/esp32-sim7000

opened by jonathandreyer 65

If optimize for performance in menuconfig, modbus failed on incomplete message (IDFGH-2371)

On latest master. Optimize for size works, but if set to Optimize for performance, I got:

Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 2 bytes (0 received)

Just change sdkconfig, no source code modified.

I'm using baudrate 230400, and I tried 115200 but still failed on the same error. ModbusSerialClient(strict=False or True) also have no effect.

Here is my test script in Python3(>=3.6):

import time

import serial

from pymodbus.client.sync import ModbusSerialClient


def reset(port, wait=1):
        with serial.Serial(port) as ser:
                ser.dtr = False
                ser.rts = False
        time.sleep(wait)


port = 'COM32'
baudrate=230400

reset(port)

client = ModbusSerialClient(
        method="rtu", strict=False,
        port=port, baudrate=baudrate, bytesize=8, stopbits=1, parity='N')
client.connect()

unit = 1
res = client.write_registers(0, [500], unit=unit)
if res.isError():
        print(f'{res}')
else:
        print('OK')

client.close()

sdkconfig and esp32 debug log also attached: SDKConfig & Log.zip

opened by keelung-yang 65

Adding WebSocket server support for esp_http_server (IDFGH-2151)

Hi all,

This Pull Request adds the WebSocket support for esp_http_server library. It mainly does:

Handling WebSocket handshake
- Parsing HTTP upgrade request
- Reply the upgrade request
Receive WebSocket packets
- Parse header, decode to a struct
- Unmask payload (if required)
Send WebSocket packets

I've tested my implementation with websocat (ref: https://github.com/vi/websocat) and it works just fine for now.

Here's a quick and dirty example for testing:

static esp_err_t ws_ping_handler(httpd_req_t *req)
{
    uint8_t buf[128] = { 0 };
    httpd_ws_pkt_t ws_pkt;
    memset(&ws_pkt, 0, sizeof(httpd_ws_pkt_t));
    ws_pkt.payload = buf;

    esp_err_t ret = httpd_ws_recv_pkt(req, &ws_pkt, 128, 60000);
    ESP_LOGI(TAG, "Got packet with message: %s", ws_pkt.payload);

    ret = ret ? : httpd_ws_send_pkt(req, &ws_pkt);
    return ret;
}

static const httpd_uri_t ws = {
    .uri        = "/ws",
    .method     = HTTP_GET,
    .handler    = ws_ping_handler,
    .user_ctx   = NULL,
    .is_websocket = true
};

static httpd_handle_t start_webserver(void)
{
    httpd_handle_t server = NULL;
    httpd_config_t config = HTTPD_DEFAULT_CONFIG();

    // Start the httpd server
    ESP_LOGI(TAG, "Starting server on port: '%d'", config.server_port);
    if (httpd_start(&server, &config) == ESP_OK) {
        // Set URI handlers
        ESP_LOGI(TAG, "Registering URI handlers");
        // ...some other HTTP endpoint handlers also add at here
        httpd_register_uri_handler(server, &ws);
        return server;
    }

    ESP_LOGI(TAG, "Error starting server!");
    return NULL;
}

Then run websocat ws://{ESP32_IP_ADDR}/ws, type in something and press Enter.

Meanwhile, I will submit some other examples soon on another Pull Request later.

Please review this Pull Request and provide some advice if possible. Thanks!

Regards, Jackson Hu

opened by huming2207 65

Issues with mdns server and now with websocket server too (IDFGH-5259)

Hi,

My mdns server and websocket server were working properly for a long time. I ended up putting the project aside for few months because i am waiting for the launch of the esp32-s3 modules.

When i came back to the project i decided to do some tests, and the mdns server was behaving strangely. Using wireshark i saw that the mdns server sent the ad for about 6 times and stopped(after manual reset). The first 4 times every 1 seconds and the last 2 times every 2 seconds and stopped. I configured mdns on menuconfig so that it would send the notification to the network every 1 second.

During this period we moved to an new internet provider and also to a new wifi router. I thought the problem could be the new wifi router, but i haven't been able to find the problem yet.

So i decided to update the esp-idf. I updated to v4.4-dev-1254-g639e7ad49.

After esp-idf update the mdns problem still persists. And now the websocket server also bugged.

Using the idf.py monitor, i can see that websocket server start ok, but when i connect to the server through my android application, the following message appears: W (00:00:08.807) httpd_ws: httpd_ws_get_frame_type: Failed to read header byte (socket FD invalid), closing socket now W (00:00:08.816) httpd_ws: httpd_ws_get_frame_type: Failed to read header byte (socket FD invalid), closing socket now

Before the update of the esp idf, the websocket server worked ok, including "ESP-IDF Release v4.2.1".

Some suggestion on how to resolve the mdns server and now the websocket server bug ?

Note: i changed the httpd priority from "config.httpd.task_priority = tskIDLE_PRIORITY + 5" to "config.httpd.task_priority = configMAX_PRIORITIES".

@david-cermak

Thank's.
Awaiting Response Status: Done Resolution: Done

opened by baldhead69 61
Feature request: toolchain for macOS aarch64 (Apple M1) hosts? (IDFGH-4262)

Is your feature request related to a problem? Please describe.

Looks like Espressif only provides ESP32 toolchains and scripts for ARM Linux hosts for now. I would like to know are there any plans for getting them working on macOS aarch64 hosts?

Describe the solution you'd like

I've bought a MacBook Pro with Apple Silicon M1 a few days ago. I'm happy to help with testing and porting later when it arrives.

So far maybe just a recompile with Espressif's crosstool-ng is fine, or maybe some slight mods are necessary. But I'm not sure.

Describe alternatives you've considered

N/A

Additional context

The status of Homebrew (we need some dependencies from it): https://github.com/Homebrew/brew/issues/7857

Status for some other dev apps (e.g. IDE): https://github.com/ThatGuySam/doesitarm
Type: Feature Request Status: Done Resolution: Done

opened by huming2207 60

Releases(v4.1.4)

v4.1.4(Dec 12, 2022)
Documentation for IDF v4.1.4 is available at https://docs.espressif.com/projects/esp-idf/en/v4.1.4/

ESP-IDF v4.1.4 is a bugfix update for ESP-IDF v4.1.3.

Obtaining v4.1.4

For full installation instructions, see the ESP-IDF Programming Guide.

The source files attached to this release will not work due to our use of git submodules. Use one of the following methods instead:

Using git

To get this release, use the following commands:

git clone -b v4.1.4 --recursive https://github.com/espressif/esp-idf.git esp-idf-v4.1.4 cd esp-idf-v4.1.4/

This is the recommended way of obtaining v4.1.4 of ESP-IDF.

Download an archive with submodules included

Attached to this release is an esp-idf-v4.1.4.zip archive. It includes .git directory and all the submodules, so can be used out of the box. This archive is provided for users who have connectivity issues preventing them from cloning from GitHub.

This archive can also be downloaded from Espressif's download server: https://dl.espressif.com/github_assets/espressif/esp-idf/releases/download/v4.1.4/esp-idf-v4.1.4.zip

Major changes

This is the list of changes since release v4.1.3:

Major Bug Fixes

Fixed deadlock due to wrong parameter when calling btc_transfer_context() after calling esp_bluedroid_disable(). (https://github.com/espressif/esp-idf/issues/9672)

Breaking Changes

Station Always connect to AP with PMF mode if possible, added a separate PMF disable API

Changelog

Bluetooth

Controller

Fixed

Fixed that FreeRTOS semaphores and queues used by Bluetooth Controller are created in SPIRAM, which causes software crash when handling ISRs

Fixed missing in processing VHCI interrupt caused by lack of protection against race conditions in accessing VHCI environment variables on ESP32

Fixed the issue that Wi-Fi task can be blocked by Bluetooth Controller because of the use of blocking coexistence callback function on ESP32

Bluetooth Low Energy

Fixed

Fixed BLE ke_mem.c assert on ESP32

Fixed BLE ASSERT_PARAM(32 0) in rwble.c at line 384 on ESP32

Classic Bluetooth

Allow max supported feature page lower than current feature page when handle with the respond of extend features to support for some devices which generate wrongly LMP respond on ESP32

Fixed the EDR mode wrongly cleared by after a successful role switch, which caused that the 2M/3M packet type can not be selected for use

Fixed the issue during legacy pairing procedure that controller does not report link key to Host on ESP32

Fixed the duplicated reports of HCI_Connection_Request event from the same Bluetooth device on ESP32

Fixed the exhaustion of ACL buffer in case of connection-disconnection stress test

Bluedroid

Classic Bluetooth

Added

Added parameter field Bluetooth device address to esp_bt_gap_cb_param_t::read_rmt_name_param. (https://github.com/espressif/esp-idf/pull/9033)

Changed

Updated HFP_HF version to 1.7.2

Fixed

Fixed the linker error of functions not defined when memory debugging functionality is enabled

Resolved type redefinitions in btc_spp.h and btc_hd.h/btc_hh.h

A2DP: Fixed the format error of AVDTP general reject message

A2DP: Fixed in A2DP sink example that audio playback is clogged due to higher priority of application task in case of heavy workload from the task

HFP: Fixed the failure of 'connect audio' operation in HFP examples with default SDK configuration

SPP: Fixed SPP initiator can not free resources when the connection fails

SPP: Fixed SPP crash after calling esp_spp_deinit

SPP: Fixed SPP resource leak due to missing of deleting the mutex upon failure of initialization

A2DP: fixed sink device not being able to accept and decode mono channel audio stream

Fixed the issue Bluetooth Classic connection can not be created while this is a Bluetooth Low Energy connection is in active

Fixed incorrect description in macro BT_CONTROLLER_INIT_CONFIG_DEFAULT()

Fixed the unexpected memory free when malloc failed (https://github.com/espressif/esp-idf/pull/9972)

HFP: Fixed the issue that HFP client makes error in parsing CLCC command response

A2DP: Fixed A2DP failing to connect again after disconnected

Bluetooth Low Energy

Fixed

Allow bluedroid host to report ADV_IND separately

Fixed bluedroid host memory overflow

Fixed calling esp_ble_get_cur_sendable_packets_num() sometimes crashes when bluetooth is disconnecting

Fixed the bug that no event is reported if the same data length is set repeatedly

Fixed second bonding failed issue

NimBLE

Fixed

Corrected stack initialization dependency function checks

ESP-BLE-Mesh

Added

Added an option for initiating IV Index Recovery if missing one

Added an option for filtering packets with old SeqAuth

Added an option for LPN to subscribe all-nodes-address automatically

Fixed

Fixed not checking the oversized SegN during provisioning

Fixed Friend not relay LPN message when relay feature is disabled

Fixed handling continuously received secure update in friend queue

Fixed using wrong range for Heartbeat Publication Period Log value

Fixed using wrong count_log for Heartbeat Subscription Status

Fixed not ignoring connectable PB-ADV PDU containing a Link Open message

Fixed ignoring KR flag within Secure Network Beacon from non-primary subnet

Fixed the sequence of checking invalid Provisioning PDU type

Fixed not using fast adv interval when PB-GATT and PB-ADV are both enabled

Fixed not checking invalid link flag during PB-GATT provisioning

Fixed wrongly overwritten the expect_ack_for flag after send_pub_key

Fixed not checking if AppKey is bound to model during model publication set

Fixed the regression introduced in the btc_transfer_context changes

Fixed not able to get optional fields from messages with a group address as DST

Wi-Fi

Changed

Compile WiFi library with -Os instead of -Og to reduce code size

Station Always connect to AP with PMF mode if possible, added a separate PMF disable API

Fixed

Fixed the bug that Wi-Fi stop stuck when sniffer not disabled

Fixed the bug that QoS null will update BA SSN which may leader packet drop by firmware

Fixed clearing default wifi netif procedure

Fixed station can't reconnect to ap when PMF enabled after deep sleep or reset

Fixed ESP-NOW can receive unencrypted packets from encrypted peer devices

Fixed some AP will ignore authentication after receiving deauthentication for a while

Fixed handling of key RSC

Fixed issue of STA does not connect to AP in mixed mode security if PMF is enabled

Fixed the QoS value of reply packets to peers

Fixed the wrong suggestion of method in NAK for all the methods (https://github.com/espressif/esp-idf/pull/7769)

Fixed write to null pointer if malloc failed

Fixed static analysis issues

Fixed an issue that station connected to an AP already connected caused subsequent scan fail

Fixed the bug that sniffer FCS error packets may cause crash

Fixed TKIP and PMF compability issue

Added changes for unicast key renew for TKIP MIC failure

Do not use pmkid caching when SSID is changed

Ignore unauthenticated encrypted EAPOL-Key data

Multiple bugfixes in SoftAP and Station PMF

Fixed memory leaks in WPS operation

Fixed the bug that stale PMF config in NVS

Fixed the bug that security parameters overwritten in full scan

Fixed unprotected SA Query issue

Peripheral Drivers

Added

SPI Flash: Support unlock for ISSI chips

SPI Flash: Added unlock function patch in bootloader to make GD flash more stable

SPI Flash: Support unlock for MXIC chips

Changed

SPI Flash: Decrease the IRAM usage of SPI Flash driver

Fixed

GPIO: Fixed the issue that config struct is not properly initialized in the example

freemodbus: Fixed slave destroy bug when master and slave init simultaneously

freemodbus: Fixed master and slave use the same timer group index (https://github.com/espressif/esp-idf/issues/4699)

freemodbus: Fixed uart_set_pin() check error in modbus master serial example

I2S: Fixed the issue that I2S DAC has no output (https://github.com/espressif/esp-idf/issues/6470)

SDIO Slave: Fixed crash caused by incorrect return value check in host example

SPI Master: Fixed the error log when using SPI_TRANS_USE_TXDATA or SPI_TRANS_USE_RXDATA with data longer than expected

SPI Slave: Fixed an issue with placing the interrupt handler into IRAM (https://github.com/espressif/esp-idf/issues/3870)

UART: Fixed uart_set_line_inverse cannot disable inverse issue

UART: Fixed RTS mis-reset before sending caused by context switch (https://github.com/espressif/esp-idf/issues/4178)

UART: Fixed unreliable uart_wait_tx_done caused by the wrong handling to legacy UART_INTR_TX_DONE event

SPI Flash: Fixed the issue mmap cannot be called with pointers to psram

Core System

Fixed

Fixed calibration failure on rtc8m clock after CPU/core reset as 8md256 clock is not enabled during calibration

Fixed xtal 32k not oscillate or oscillate too slowly issue for ESP32

FreeRTOS

Fixed

Fixed bug in Xtensa FreeRTOS port where extra threadptr CPU was not being saved on solicited context switches

Fixed bug in event group functions where blocked task list was being accessed without acquiring the task list spinlock

Power Management

Fixed

Fixed problem when idle task neither enters light sleep nor "waiti" state

LWIP

Fixed

Fixed esp_netif_set_dns_info() API to work correctly with IPv6 addresses

Bootloader

Added

Enable write protection to flash at end of bootloader to increase stability

Changed

Improved XMC flash stabilities as main flash

Fixed

Avoid unnecessary WRSR operation to flash to increase stability

Storage

Fixed

NVS: Fixed issues found by Coverity

Tools

Added

Docker: Add build argument IDF_CLONE_SHALLOW in order to reduce the image size

Changed

Upgrade OpenOCD version to v0.11.0-esp32-20220706

Fixed

Fixed installation on Ubuntu 22.04 (and probably later versions) (https://github.com/espressif/esp-idf/issues/9931)

Build System

Added

Enable the component manager for pure CMake builds by default

Fixed

Fixed an issue where disassembly of ELF files built with ESP-IDF would sometimes be incorrect. The issue was related to .xt.prop sections missing from the final ELF file

Source code(tar.gz)
Source code(zip)
esp-idf-v4.1.4.zip(811.08 MB)