Arduino 3.0.x doesn't work with RMT Legacy Driver #9866
Comments
|
Does it also happen if you use this: https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/esp32-hal-rgb-led.h#L14 |
|
Short answer is yes, using Real question is why does Enabling USB CDC On Boot crash the legacy RMT driver at runtime while Disabling USB CDC On Boot does not? |
|
Agree on the real question. @SuGlider will have a look |
|
@Xylopyrographer - I see that your project does Arduino Core 3.0.x (IDF 5.1) uses new drivers from I think that there is a mix of many thing here that have a conflict, exactly as reported in the issue: Regarding CDC On Boot, I only can guess that it may lead to initialize the new Arduino RMT driver, somehow. |
|
@SuGlider, thanks for the reply. Couple of points: The RMT driver, though legacy, is included in ESP-IDF v5.x and as well in arduino-esp32 core 3.0.x. Given that any RMT code moving from IDF 4.x to 5.x has to be rewritten from the ground up to use the new API's, inclusion of the legacy driver in the IDF 5.x and core 3.0.x releases is the wise and correct thing to do. So the issue is, the example above (which uses only the legacy ESP-IDF driver) runs 100% on targets where USB-CDC On Boot is Disabled (or where USB CDC is not available on the target SOC) but fails as noted when USB-CDC On Boot is Enabled. As the S3 has a complete and separate USB OTG peripheral (in addition to the USB Serial/JTAG peripheral), why would Enabling USB CDC on Boot do anything with the RMT peripheral? Were you able find from where |
|
@Xylopyrographer both drivers should never be used/compiled together. We have moved to the new driver and so should you :) Maybe start using the Arduino layer for it from now on? |
|
@me-no-dev Agree that at some point, moving to the new world order is the thing to to. In the mean time, the legacy driver is included in core 3.0.x and does work, except when USB-CDC On Boot is Enabled. The sample sketch uses calls only to the legacy ESP-IDF v4.4.x driver. Neither the new ESP-IDF v5.x.y RMT drivers nor the new arduino-esp32 core 3.0.x RMT drivers are included or called. The issue is, why would enabling USB-CDC On Boot cause an RMT conflict? |
I'll investigate this odd relation. |
|
This is the IDF place where it causes the error ( /**
* @brief This function will be called during start up, to check that this legacy RMT driver is not running along with the new driver
*/
__attribute__((constructor))
static void check_rmt_legacy_driver_conflict(void)
{
// This function was declared as weak here. The new RMT driver has one implementation.
// So if the new RMT driver is not linked in, then `rmt_acquire_group_handle()` should be NULL at runtime.
extern __attribute__((weak)) void *rmt_acquire_group_handle(int group_id);
if ((void *)rmt_acquire_group_handle != NULL) {
ESP_EARLY_LOGE(TAG, "CONFLICT! driver_ng is not allowed to be used with the legacy driver");
abort();
}
ESP_EARLY_LOGW(TAG, "legacy driver is deprecated, please migrate to `driver/rmt_tx.h` and/or `driver/rmt_rx.h`");
} |
|
I have tested the LiteLED sketch and it fails only when Based on the IDF code, it looks like a linking issue... For example, this code with static const uint8_t currBright = 20; // change this to set the brightness level of the matrix
static const crgb_t BLINK_COL = 0x00002f;
LiteLED myDisplay( LED_TYPE, LED_TYPE_IS_RGBW ); // create the LiteLED object
void setup() {
pinMode(2, OUTPUT);
digitalWrite(2, HIGH);
delay( 2000 );
printf( "printf: Sketch in setup()" );
Serial.begin( 115200 );
delay( 2000 );
Serial.println( "Sketch in setup()" );
myDisplay.begin( LED_GPIO, 1, 0 ); // initialze the myDisplay object.
myDisplay.brightness( currBright );
myDisplay.setPixel( 0, BLINK_COL, 1 );
}
void loop() {
// blink a pixel
myDisplay.brightness( 0, 1 );
delay( 1000 );
myDisplay.brightness( currBright, 1 );
delay( 1000 );
} |
|
just the |
|
The reason for that is because in The code that has it in HAL GPIO is: extern void ARDUINO_ISR_ATTR __digitalWrite(uint8_t pin, uint8_t val) {
#ifdef RGB_BUILTIN
if (pin == RGB_BUILTIN) {
//use RMT to set all channels on/off
RGB_BUILTIN_storage = val;
const uint8_t comm_val = val != 0 ? RGB_BRIGHTNESS : 0;
neopixelWrite(RGB_BUILTIN, comm_val, comm_val, comm_val);
return;
}
#endif
if (perimanGetPinBus(pin, ESP32_BUS_TYPE_GPIO) != NULL) {
gpio_set_level((gpio_num_t)pin, val);
} else {
log_e("IO %i is not set as GPIO.", pin);
}
} |
|
@Xylopyrographer - If the board used has no RGB_BUILTIN definition in its |
|
An example of S3 board that has no
|
|
@Xylopyrographer - Therefore, the solution to this puzzle is the call to any GPIO function, in a board that has Both CDC drivers call |
This is not correct... if the sketch uses |
SuGlider
added
Resolution: Wontfix
|
@SuGlider Very much appreciate the in-depth analysis. Dealing with a death in the family at this time, will then need some time to absorb it all and get back to you. |
|
Please check the PR #9941 - It creates a way to completely disable the New RMT Driver within Arduino Core 3.0.x. |
SuGlider
changed the title
Board
ESP32S3 Dev Module
Device Description
ESP32S3 Dev Module with an on-board WS2812 RGB LED on GPIO48.
Hardware Configuration
No
Version
v3.0.1
IDE Name
Arduino IDE 2.3.2
Operating System
Debian 12
Flash frequency
Flash Mode: "QIO 80MHZ"
PSRAM enabled
yes
Upload speed
921600
Description
When using the legacy RMT driver as per:
https://docs.espressif.com/projects/esp-idf/en/v5.1.4/esp32/migration-guides/release-5.x/5.0/peripherals.html#rmt-driver
and when USB CDC On Boot is set to "Disabled" the sketch below runs.
If however USB CDC On Boot is set to "Enabled" the sketch crashes into a boot loop. Crash log is below.
The LiteLED library uses only ESP-IDF calls.
To test, must use the LiteLED v3 development branch at: https://github.com/Xylopyrographer/LiteLED/tree/v1.3
Sketch
Debug Message
Other Steps to Reproduce
Crash occurs whenever USB CDC On Boot is enabled, regardless of other USB settings and whether PSRAM is enabled or not.
Serial monitor output with Core Debug Level: "Debug" and USB DFU On Boot: "Disabled":
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: