Chip support: ESP32-C2

[lybgo]

Related area

Board support

Hardware specification

ESP32-C2

Is your feature request related to a problem?

When will ESP32-C2 be supported

Describe the solution you'd like

When will ESP32-C2 be supported

Describe alternatives you've considered

No response

Additional context

No response

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.

[lbernstone]

Roadmap is at https://github.com/orgs/espressif/projects/3/views/5. As you can see, C2 is not even on the map. It must be well supported by IDF before it will appear here.

[VojtechBartoska]

Hello @lybgo, we wanted to open new ticket but I will use yours for tracking this support. Adding it on the Roadmap.

The support itself is under discussion. We need to evaluate if it make sense to support ESP32-C2 for Arduino ESP32 Core.

The resolution will be shared in this ticket.

[VojtechBartoska]

Hello folks,

we discussed internally support of ESP32-C2 and we are sharing current state.

---

Please be aware that this resolution can change in the future depending on other factors and requests as amount of maker-oriented devboards made with ESP32-C2 in the future for example. Also any community effort is welcomed

---

At this moment we are not going to add support for ESP32-C2, this SoC will be mainly used in large volume commercial applications due to cost-reduction and for that can be used ESP-IDF.

In Arduino ESP32 Core from our perspective, ESP32-C3 has a lot more RAM and more peripherals and the price is just a bit higher so it make more sense to use and support ESP-C3 than ESP32-C2.

---

We will instead focus on adding first ESP32-H2 support, which is bringing new applications. ESP32-H2 support is tracked in this issue.

[ITstreet1]

Any news regarding ESP32C2 (ESP8684) as there are dev kits based on it:
https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp8684/esp8684-devkitm-1/index.html

[me-no-dev]

@ITstreet1 as @VojtechBartoska explained, we do not currently plan to add support for C2 in Arduino. It is possible that we add support so that you can use Arduino as IDF component or build your own libraries for it to use with Arduino IDE.

[ITstreet1]

Yeah, I read that. But thought you might change your plans. Hope you will add the support as there are dev kits. The MCU is so small and can be easily fitted into many devices.

I will stay tuned, anyway.

Regards.

[rkarlsba]

I just got my hands on some ESP32-C2s and I would very much like this support. AFAICS, it should be mostly the same as the ESP32-C3

[Jason2866]

@lybgo @rkarlsba @ITstreet1 @lbernstone @me-no-dev
Added C2 support to the current branch esp-idf-v5.1-libs. It is here https://github.com/tasmota/arduino-esp32/tree/esp-idf-v5.1-c2
The corresponding libs are here https://github.com/tasmota/esp32-arduino-libs

Built with forked Arduino Lib Builder (branch) https://github.com/Jason2866/esp32-arduino-lib-builder/tree/v5.1_c2_try

Did NOT test with ArduinoIDE since i dont use. Tests done with Platformio. The full Platformio Arduino framework is here https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/1440/framework-arduinoespressif32-release_v5.1-3d4f85e3f4.zip

Can be used with this Platformio setup:

[env:esp32-c2-devkitm-1]
platform = https://github.com/Jason2866/platform-espressif32.git#Arduino/IDF5
framework = arduino
board = esp32-c2-devkitm-1
monitor_speed = 115200

Tested wifi, serial and simple LED blink. All worked. Some stuff will not work since the C2 does NOT support RMT!!

Screenshot from example sketch WifiScan.ino (serial port)

Thx @VojtechBartoska for providing the esp8684 devkit

[HalfSweet]

@lybgo @rkarlsba @ITstreet1 @lbernstone @me-no-dev为当前分支esp-idf-v5.1-libs添加了C2支持。它在这里https://github.com/tasmota/arduino-esp32/tree/esp-idf-v5.1-c2相应的libs在这里https://github.com/tasmota/esp32-arduino-libs

使用分叉的Arduino Lib Builder（分支）构建https://github.com/Jason2866/esp32-arduino-lib-builder/tree/v5.1_c2_try

没有用ArduinoIDE进行测试，因为我没有使用。使用Platformio完成的测试。完整的Platformio Arduino框架在这里https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/1440/framework-arduinoespressif32-release_v5.1-3d4f85e3f4.zip

可以与此Platformio设置一起使用：

[env:esp32-c2-devkitm-1]
platform = https://github.com/Jason2866/platform-espressif32.git#Arduino/IDF5
framework = arduino
board = esp32-c2-devkitm-1
monitor_speed = 115200

测试了wifi，串行和简单的LED闪烁。全部起作用了。有些东西不起作用，因为C2不支持RMT！！

示例草图WifiScan.ino（串行端口）的屏幕截图

谢谢@VojtechBartoska提供esp8684 devkit

This is great. It works.

But there is a problem, it builds by default with a 26M crystal, while some chips use 40M, which can cause the application to crash. Can we add a build option to avoid this?

As well, will this eventually merge into the main Arduino-esp32 thread?

[TD-er]

But there is a problem, it builds by default with a 26M crystal, while some chips use 40M, which can cause the application to crash. Can we add a build option to avoid this?

Better to have it detected at runtime (preferably in the bootloader).
If I'm not mistaken, something similar has been done for ESP8266.

[HalfSweet]

Better to have it detected at runtime (preferably in the bootloader).
If I'm not mistaken, something similar has been done for ESP8266.

Can the frequency of the crystal be acquired at runtime? This is not very clear to me.

But what is certain is that if a 26M configuration is used and the hardware is using a 40M crystal, it will cause the core to crash, and based on the logs, this seems to happen during the bootloader phase.

[TD-er]

It probably bases the SPI bus frequency on the assumed crystal frequency.
So that's why the clock frequency must somehow be detected in the bootloader.

Not sure if there is some other clock like for example some 32 kHz RTC clock or some other internal clock which isn't based on the 26/40 MHz crystal.

[Jason2866]

The clock frequency is a compile time option when building the Arduino libs (sdkconfig).
Afaik there is no possibility to switch the clock during runtime.
The side effect i saw was the wrong UART speed. Device did NOT crash with wrong choosen clock.
Will not investigate further. If someone does find a solution, PRs to my fork are welcome.
(Btw. project Tasmota does start and is working with core functions already on the C2. Adopted OneWire Lib is working and shows values from a DS18B20 already).

[Jason2866]

Better to have it detected at runtime (preferably in the bootloader).
If I'm not mistaken, something similar has been done for ESP8266.

The bootloader from the esp8266 is completely build in Arduino code. It is a compile time option too. No switching anywhere in code. This approach is not possible with ESP32-xx since bootloader is compiled in IDF framework.

The only way is to identify where the changes are in compiled object files and use the one(s) needed for the clock choosen. Same way as it is done for different flash modes and speeds.

[HalfSweet]

The clock frequency is a compile time option when building the Arduino libs (sdkconfig). Afaik there is no possibility to switch the clock during runtime. The side effect i saw was the wrong UART speed. Device did NOT crash with wrong choosen clock. Will not investigate further. If someone does find a solution, PRs to my fork are welcome. (Btw. project Tasmota does start and is working with core functions already on the C2. Adopted OneWire Lib is working and shows values from a DS18B20 already).

But I am running the bootloader compiled with 26M on a 40M device, maybe this will cause a crash by exceeding the maximum mains frequency.

Is it possible to provide several different pre-built bootloaders that have been adapted to different crystals and different flashes, which seems easy enough to do?

[TD-er]

But I am running the bootloader compiled with 26M on a 40M device, maybe this will cause a crash by exceeding the maximum mains frequency.

That makes perfect sense.
For 26 MHz, the multiplier to get to your flash frequency is higher than when 40 MHz is assumed.
So if you build it for 26 MHz, you will run your flash at a higher frequency on a 40 MHz node.

The most "safe" option is to build for 40 MHz clock, or set the flash frequency to a lower value.

Not sure what is all derived from this crystal frequency.
Things I would expect to be derived:

• Clock frequency
• Serial
• SPI bus
• "80 MHz" timer
• WiFi ???
• Adruino 'millis()' ??
• RTOS timers ??

Anyway, it sounds quite bad that we might require 2 builds to support the C2...
Could the multiplier/ratio be set in some register in our own sketch?

[Jason2866]

Is it possible to provide several different pre-built bootloaders that have been adapted to different crystals and different flashes, which seems easy enough to do?

You are welcome to do. Everything is online in github. Just fork :-)

[VojtechBartoska]

Support for ESP32-C2 was added here: #8881 by @Jason2866 + help of Arduino Core developers, it is not a full support including Boards manager availability, you need to build libraries on your own.

[TD-er]

About the 40MHz X-tal question.
See also the ESP8684 Series SoC Errata

3.1 40 MHz crystal cannot work
Description
ESP8684 was designed to support 26 MHz and 40 MHz crystals. However, for revision v1.0 and previous
versions, some chips cannot work properly when equipped with 40 MHz crystal. Specific symptoms of the
problem include clock issues, or printing garbled characters when powering on, etc.
Workarounds
Use 26 MHz crystal instead of 40 MHz for revision v1.0 and previous chips.
Projected Solution
This issue has been fixed in revision v1.1, which supports both 26 MHz and 40 MHz crystals.

[me-no-dev]

Even if we add support, it would be more or less like the OPI case for S3. You would need to know what XTAL is under the can of your module, in order to pick the correct option.

[VojtechBartoska]

Closing this ticket in favour of #8881.