[Solved] BLE Advertising seems to corrupt RMT signals [used for led_strip]

[dconyers]

Hello -
First, many thanks in advance for any tips/hints you may be able to provide. I've been fighting with this for about a week and have run out of ideas, so many thanks for any assistance you might be able to provide!

Setup

• I'm using a Sparkfun ESP32 Things Plus (USB-C) (WRL-20168) that uses the ESP32-WROOM-32E.
• I have a Neopixel Stick with the SKC6812 LEDs attached to pin 2 (although the pin doesn't matter - I can reproduce on other pins as well).
• I'm using esp-idf v5.4

  Code: Untitled.txt Select all

  dconyers@Mac led_ble_test_app % idf.py --version
  
  ESP-IDF v5.4-552-ge37d33cc1c

Code
I have created the simplest possible reproduction application in Github here. I originally wrote the code to include the Espressif LED_Strip component, but the link above shows the version that only uses the RMT component just to remove the component as a potential source of the issue.

Steps to Reproduce
The Neopixel has a total of 8 addressable LEDs. I have set the code to only populate 5 LEDs. Because I'm using GPIO Pin #2 on the Sparkfun board, that means that it will drive the onboard LED plus half of the LEDs on the Neopixel Stick. When I run the code, at some (seemingly) random point in the first 2 minutes, the other LEDs will be lit.

If the

Code: Select all

ble_advertise()

is commented-out, the problem does NOT occur. This leads me to believe that there is some sort of interrupted-related issue, but this example is so incredibly simple that it seems hard to believe. To that end, I have specifically moved the LED activities to the second core, but the issue remains. Regardless, I believe all the actual signal generation is happening based on interrupts, so I'm not sure this is even relevant, but I've got it setup to use both cores:

Code: Untitled.txt Select all

I (5786) TaskMonitor: Task count: 10

I (5786) TaskMonitor: Task: LED Controller  | Core: 2 | Priority: 5

I (5786) TaskMonitor: Task: main | Core: 1 | Priority: 1

I (5786) TaskMonitor: Task: IDLE0 | Core: -1 | Priority: 0

I (5796) TaskMonitor: Task: IDLE1 | Core: -1 | Priority: 0

I (5796) TaskMonitor: Task: ipc0 | Core: 1 | Priority: 24

I (5806) TaskMonitor: Task: ipc1 | Core: 2 | Priority: 24

I (5806) TaskMonitor: Task: Tmr Svc | Core: -1 | Priority: 1

I (5816) TaskMonitor: Task: esp_timer | Core: 1 | Priority: 22

I (5816) TaskMonitor: Task: nimble_host | Core: 1 | Priority: 21

I (5826) TaskMonitor: Task: btController | Core: 1 | Priority: 23

Narrowing Down the issue.
I setup my picoscope and put it on the data line between the Sparkfun board (after the internal LED) and the NeoPixel. Normally, I see the output such as the following:


When I record the oscilloscope capture and then see the corruption, I can find a message such as the following:


I don't know of any alternatives at this point as the ESP32-WROOM doesn't support DMA, so I'm at a bit of a loss.. I'm happy to continue working on this, but wanted to post this in hopes someone with more experience might be able to nudge me in the right direction. Much appreciated in advance for any help that can be provided!

[Sprite]

Can you try setting in mem_block_symbols to e.g. 128 in your rmt_tx_channel_config_t? If your issue is that BLE uses too much blocking CPU time, that may give the RMT a bit more space to deal with the added latency.

[dconyers]

Wow, just wow! Yes, that seems to have fully addressed the issue, thank you!

I reviewed the source code in the rmt component... Should the value specified in mem_block_symbols be a multiple of SOC_RMT_MEM_WORDS_PER_CHANNEL (48) when DMA isn't used?

I am still a bit confused on why/how this resolves the issue, but it certainly seems to, so that's great! The thing I didn't share in my original post is that the corrupted message is sent out at exactly the correct time (meaning the transmission wasn't delayed), so can you please shed some light on why increasing the buffer size addresses the issue?

once again, thanks so much - you're brilliant and the issue seems to be fully resolved; I just want to learn a bit more about how/why this fixes the issue!

Thank You - Doug.

[Sprite]

Wow, just wow! Yes, that seems to have fully addressed the issue, thank you!

I reviewed the source code in the rmt component... Should the value specified in mem_block_symbols be a multiple of SOC_RMT_MEM_WORDS_PER_CHANNEL (48) when DMA isn't used?

It should, but you're using the (original, non-S, non-C, non-H) ESP32, and it's 64 there.

I am still a bit confused on why/how this resolves the issue,

In your original setup, the RMT can only hold 64 items, and you need to send (24 bits * 5 LEDs + 1 reset bit =)121 items. In order to do that with 64 items of hw memory, the RMT driver sets an interrupt to go off when the RMT has sent 50% of the data, so it can come in and re-fill the buffer with new data to be sent. However, this only works if the interrupt is serviced fast enough: when it is held up by e.g. a BT interrupt, it can take too long and the RMT will send the other 50% and then runs out of data, leading to corruption. By allocating 128 bytes, you give the RMT more buffer so it takes longer to run out of data; in your particular case, the entire thing will actually fit into the buffer so you don't have a chance of running out at all.

[dconyers]

Thank you so much for your comprehensive explanation. I've now reviewed the encoder code in more detail and completely see how a single bit of data has to be tracked as a word (32-bits) of encoded data...

Much appreciate all of your help, thank you!