RMT on ESP32-C3 Super Mini

[suprstefan]

I'm trying to get RMT working on this board (but bought from AliExpress):
https://www.tindie.com/products/adz1122/esp32-c3-development-board-esp32-supermini/

Here's the code I use for testing purposes:

#include <NeoPixelBus.h>

const uint16_t PixelCount = 1;
const uint8_t PixelPin = 10;

NeoPixelBus<NeoGrbFeature, NeoWs2812xMethod> strip(PixelCount, PixelPin);

void setup()
{
    strip.Begin();
    strip.Show();
}

void loop()
{
  strip.SetPixelColor(0, RgbColor(255,0,0));
  strip.Show();
  delay(1000);

  strip.SetPixelColor(0, RgbColor(0,255,0));
  strip.Show();
  delay(1000);

  strip.SetPixelColor(0, RgbColor(0,0,255));
  strip.Show();
  delay(1000);
}

If I use NeoEsp32BitBangWs2812xMethod it works great but if I try either NeoWs2812xMethod or NeoEsp32Rmt0Ws2812xMethod it doesn't. I've tried four different pins and I get the same behavior. Since I wasn't entirely sure what was going on I hooked up a logic analyzer to the output pin and with the bitbang method I get this:

Which looks great. When I change to one of the RMT methods I get this:

Which obviously isn't great :)

This is with ESP32 arduino core 3.0.4 and NeoPixelBus 2.8.0.

Does anyone have any idea of what the issue might be? Is there some way to debug it or get more info?

[suprstefan]

Ah, I enabled "Optimize for Debugging" to get the error checking and then I got infinite reboot and the serial monitor gave me:

Rebooting...
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
Saved PC:0x40048b82
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0x1058
load:0x403cc710,len:0x8a8
load:0x403ce710,len:0x2fa0
entry 0x403cc710
E (76) rmt(legacy): CONFLICT! driver_ng is not allowed to be used with the legacy driver

abort() was called at PC 0x42006f71 on core 0
Core  0 register dump:
MEPC    : 0x40381b5e  RA      : 0x403849e6  SP      : 0x3fcde210  GP      : 0x3fc8c400  
TP      : 0x00000000  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130  
S0/FP   : 0x3fcde23c  S1      : 0x3fcde23c  A0      : 0x3fcde248  A1      : 0x3fcde22a  
A2      : 0x00000000  A3      : 0x3fcde275  A4      : 0x00000001  A5      : 0x3fc8f000  
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x3c034000  S3      : 0x3fc8e1b4  
S4      : 0x0000f508  S5      : 0x3c030000  S6      : 0xffff0000  S7      : 0x40381b70  
S8      : 0x00020020  S9      : 0x00010020  S10     : 0x00000005  S11     : 0x3fcde3c0  
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938  
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000  
MHARTID : 0x00000000

Some quick googling pointed to this being an issue with ESP-IDF 5. I switched to ESP32 core 2.0.17 (which is the latest using ESP-IDF 4) and then it works great.

[Makuna]

Yeah, this issue is tracking this for my library.