Espressif Leaks ESP32-C3: A WiFi SoC That’s RISC-V And Is ESP8266 Pin-Compatible

Six years on from the emergence of the Espressif ESP8266 we might believe that the focus had shifted to the newer dual-core ESP32. But here comes a twist in the form of the newly-revealed ESP32-C3. It’s a WiFi SoC that despite its ESP32 name contains a RISC-V core in place of the Tensilica core in the ESP32s we know, and uses the ESP8266 pin-out rather than that of its newer sibling. There’s relatively little information about it at the time of writing, but CNX Software have gathered together what there is including a draft datasheet whose English translation is available as a Mega download. As with other ESP32 family members, this one delivers b/g/n WiFi and Bluetooth Low-Energy (BLE) 5, where it differs is the RISC-V 32 Single-core processor with a clock speed of up to 160 MHz. There is 400 kB of SRAM and 384 kB ROM storage space built in.

While there is no official announcement yet, Espressif has been dropping hints. There’s been an OpenOCD configuration file for it in the Espressif repositories since the end of last month. And on Friday, Espressif Software Engineering Manager [Sprite_tm] answered a reddit comment, confirming the RISC-V core.

ESP-01: Kjerish, CC BY-SA 4.0, RISC-V logo: RISC-V foundation, Public domain.

Why they are releasing the part as an ESP32 rather than giving it a series number of its own remains a mystery, but it’s not hard to see why it makes commercial sense to create it in an ESP8266-compatible footprint. The arrival of competing parts in the cheap wireless SoC space such as the Bouffalo Labs BL602 we mentioned recently is likely to be eating into sales of the six-year-old chip, so an upgrade path to a more capable part with minimal new hardware design requirements could be a powerful incentive for large customers to stay with Espressif.

We’re left to guess on how exactly the rollout will proceed. We expect to see similar developer support to that they now provide for their other chips, and then ESP32-C3 powered versions of existing ESP8266 boards in short order. It’s also to be hoped that a standard RISC-V toolchain could be used instead of the device-specific ones for current Espressif offerings. What we should not expect are open-source replacements for the blobs that drive the on-board peripherals, as the new chip will share the same closed-source IP as its predecessors for them. Perhaps if the PINE64 initiative to reverse engineer blobs for the BL602 bears fruit, we might see a similar effort for this chip.

56 thoughts on “Espressif Leaks ESP32-C3: A WiFi SoC That’s RISC-V And Is ESP8266 Pin-Compatible

    1. I want to know one thing: Am I still going to have to put up with an inscrutable blob constantly running in the background that sits between me and the wifi radio and has full access to the internet?

      I’m very disappointed that nobody in the last 6 years has developed a replacement for this radio library, even as we’ve seen people tackle the Raspberry Pi’s VPU firmware.

      1. Can this blob spy on traffic? There is a wifi repeater in Arduino ide. Can the esp monitor your passwords/websites/etc, and send the data to a 3rd party (possibly even if only .1% of the time to hide its mischief)?

          1. Very likely, as the blob is the one doing the encryption en decryption. There are calls into the library to open an ecrypted connection to a remote side, so the library gets unencrypted data, encrypts it to protect against in-transit-listeners and then sends it off.

    2. Although… not all RISC-V cores are open. Many are, many aren’t. The completely open thing about RISC-V is it’s Instruction Set Architecture, which anyone can implement without paying an architecture license. And there are some fairly decent open source core generators (BOOM, Rocket, etc.) But there’s more to a core than its verilog representation or the ISA and Si-Five’s business model is selling proprietary cores based on proprietary Rocket enhancements.

      There are PLENTY of high-quality open source cores / generators available (Vex, Pico, Swerve, Rocket, etc.) But some commercial organizations appreciate Si-Five because they can: a) integrate proprietary IP on a SoC without violating the core’s license and b) have a team of people verifying the core’s correctness. (And they have a number of other professional services if you’re not hip to Route and Place or the black magic that seems to be interfacing with DRAM.)

      Which is to say… it’s possible the CPU core might not be open.

      Which is a very verbose way to say… a low-end single-core power-efficient FPGA in an ESP32 form factor w/ various peripherals with enough gates to implement at least one RV32 core would be pretty awesome. People could (if they really wanted to) experiment with modifying open cores like Pico or Vex to add new instructions or add new peripherals.

      [Full Disclosure: I used to work for Si-Five, but certainly don’t speak on their behalf. I just got to see their verification and validation process up close and think they’re doing some interesting things.]

  1. Ooh, I’m definitely intrigued! Even with the proprietary blob, Espressif has otherwise wholly embraced the DIY-community and nowadays their ESP32 SDK is great. I totally expect something similar for this one as well.

  2. Looking at the specsheet, it’s immediately got the leg up on ESP8266 in multiple areas: proper hardware I2C and PWM, both of which are software-based on the 8266, 2x 12bit ADC against ESP8266’s single 10bit, hardware AES and TRNG — that’s already quite a lot good stuff. Presumably lower power-consumption and more capable power-management features as well!

  3. Really hoping they fork the series name, rather than having such a small naming change signify a whole different architecture. What if they keep doing C4, C5, C6, C7 etc with random switches between Tensilica and RISC-V cores?

    1. Espressif guy here: Because the core change in general is something our customers won’t really notice. You write your code in C (or Arduino, or MicroPython, or Lua, or…) and you compile it against ESP-IDF, just like all other processors. For our end users of the chip and sdk, things like amount of pins and peripherals is way more of a deciding factor.

      1. Ah someone from the club, cool good to hear from you Sprite_tm, pray can you clarify:-

        1. What’s the easiest path for assembler ie some IDE & loader suitable for the 8266 ?
        2.Would that same IDE/method apply to ESP-32 ?

        3. For either 1 or 2 is system source rom available as a published document or otherwise, perhaps under a NDA ?
        4. I guess for this new ESP32-C3 with the core non proprietary the firmware published ?

        Haven’t had the opportunity as yet to go through all the various paths, lot on my plate but keen to get back to the first 2 and this new configuration, thanks

        1. You will be able to download ESP-IDF, as you have for the ESP32, and use it to compile code for the -S2 and -C3 that way. It pulls in gcc/binutils for the needed CPU core automatically. Not sure wrt ROM source code, but the stuff either is not that interesting (e.g. newlib routines) or we can’t easily release the sources (low-level PHY routines), so I don’t think that’s going to have a super-high priority. We’ll probably be releasing ELFs so you can at least see what functions are called into from your ESP-IDF program, but again, no promises there. On ‘non-proprietary firmware’ – what firmware do you refer to? Radio stuff will still be closed because of a plethora of reasons, and I don’t think we have any other blobs remaining in ESP-IDF anymore, but feel free to correct me if I’m wrong.

          1. I think you’re underestimating the interest with something with a V core – I mentioned it to a few people today – who I haven’t been able to get interested in the esp32 – and they were instantly interested.
            You also probably underestimate how many people (me included) build things with the esp32 (not s2) in them with the wifi and bluetooth very very turned off. I love two cores..

            In fact, the only issues I’ve had with it is things that need real time deterministic timing (can’t do because of rtos etc, though can do some with the RMT), and the real crappy i2c slave support – I had to write my own from scratch as I’m doing a few things with two esp32 on board.. (the issues are mentioned many times on the esp32 forum..).

          2. That’s a bit unfortunate.
            I’d love to have access to the transmit and receive IQ registers of the DSP, the frequency setting register and the PA power control register.

            But I can understand the RF side being closed due to IP licensing and regulatory reasons.

            We did SDR reception on SiLabs EFR32 by reading from the DSP cores IQ registers, which thankfully ware documented.
            The FM transmit and small frequency step stuff we had to reverse engineer from the “RAIL” RF HAL library provided by silabs.
            But on the upside we got a 2400MHz handheld SDR radio and later one with 140-960MHz coverage in addition the 2320-2700MHz we had in the mono band 2400MHz version :)

            An ESP based “geckokapula” would rock and the core in ESP’s is fast enough to run codec2 or some other digital voice codec. Unlike the 38.4MHz Cortex-M4F core in EFR32 series.

          1. checked the datasheet linked above and it says “• State-of-the-art power and RF performance” and “Applications: smart watch and bracelet”, so should be made for it. e.g. Dialog DA1469x has larger SRAM , also SPI flash with no onboard flash is typical on such ‘dedicated’ BLE chips too. There should be no excuse. The BL602 referenced in article has wifi too so not sure what ‘dedicated’ means exactly.

      2. One of my favorite things about Espressif stuff is that everytime there is a leak, release etc. an employee or former employee shows up the comments with something more than marketing speak to contribute.

      3. I suppose not noticing the core change depends on which customers you’re describing. All of your customers here would definitely notice and would appreciate a better naming scheme.

    2. If it’s like VIA then there will not be a C4. C4 is an explosive, and VIA had to rename the VIA C4 the C5 because otherwise it was not going to pass through airport customs/security.

    1. Hi Jeroen, hi folks,

      ESP32-C3 Family
      Ultra-Low-Power SoC with RISC-V Single-Core CPU
      Supporting 2.4 GHz Wi-Fi and Bluetooth LE
      – ESP32-C3
      – ESP32-C3FN4
      – ESP32-C3FH4

      Draft V 0.3 is updated


      Prerelease V 0.4 is public online

      public Info
      BBS ESP32

      ESP32-C3 Datasheet
      V0.4 27 Nov 2020

      ESP32-C3 技术规格书
      V0.4 2020年11月27日

      best wishes
      rudi ;-)

  4. The pin compatibility part is mistranslated. The Chinese announcement says modules are pin compatible.

    Both chips in 5×5 QFN 32 pin but look at the pinouts, pins different including antenna (pin 1 vs pin 2). PCB designs still need some changes.

  5. The datasheet is mum about the USB peripheral, except that the features list teases “USB 1.1 interface (USB to UART converter, USB to JTAG converter)”. Does that mean we’ll plug it into a USB port and not only get a console TTY but also JTAG debugging? That would be sooo coool! Does the esp32-s2 already have that and I’ve just been asleep?

    1. Note that the datasheet still is a draft, so no official guarantees that anything will be in the final chip, but that’s pretty much our intent for that peripheral. The -S2 does not have it; it has a software-controllable OTG device instead which can be configured to act like either a host or a random peripheral, but doesn’t do JTAG.

  6. Read the pdf.
    Beautiful chip that ticks all the boxes as a IoT builder I’m looking for.
    Is this Ethernet MAC compatible? It mentions WiFi MAC but not Ethernet.
    That’s something we require for security and reliability reasons.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.