Esp-idf: Crash when RMT mem_block_num > 1 (IDFGH-2915)

Created on 19 Mar 2020  Â·  13Comments  Â·  Source: espressif/esp-idf

Environment

  • Development Kit: ESP32-WROOM
  • Module or chip used: ESP32D0WDQ5 (revision 1)
  • IDF version: v4.1-dev-2079-g5dbabae9d
  • Build System: make
  • Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0
  • Operating System: Windows subsystem for Linux
  • Using an IDE?: No
  • Power Supply: external 5V

Problem Description

When rmt_config is called with rmt_config_t containing mem_block_num value > 1, then a hard crash occurs in rmt translation function.

Expected Behavior

Using > 1 mem_blocks used to work (I think on v4.0)

Actual Behavior

Hang, resulting in WDT trigger

Steps to reproduce

  • start with the rmt/led_strip sample
  • set RMT_TX_CHANNEL == 0
  • add the following at line 83 of led_strip_main.c
    config.mem_block_num = 8;
  • build and run

Code to reproduce this issue

https://gist.github.com/cskilbeck/6ce188fd980637f194f454d5bdd43037

Debug Log

https://gist.github.com/cskilbeck/56da4ad34c9c9bb4d04efe092b5cb632

Other items

Most helpful comment

Hi,@cskilbeck
Thanks for reporting this issue, this is a issue introduced by driver refactoring. We will fix it soon.

thanks !!

All 13 comments

@cskilbeck Thanks for reporting. Would you please help provide more details as suggested in the issue template? Information like elf, sdk configuration, backtrace, log outputs, commit ID, hardware and etc. would help us debug further. Thanks.

Hi, @cskilbeck
Do you want to drive an WS2812 LED strip with RMT? you can refer to https://github.com/espressif/esp-idf/tree/master/examples/peripherals/rmt/led_strip
thanks !!

From looking at the debug log, it seems to be having a problem in rmt_ll_write_memory, called from line 519 in driver/rmt.c

static void IRAM_ATTR rmt_fill_memory(rmt_channel_t channel, const rmt_item32_t *item,
                                      uint16_t item_num, uint16_t mem_offset)
{
    RMT_ENTER_CRITICAL();
    rmt_ll_set_mem_owner(p_rmt_obj[channel]->hal.regs, channel, RMT_MEM_OWNER_SW);
    rmt_ll_write_memory(p_rmt_obj[channel]->hal.mem, channel, item, item_num, mem_offset);
    rmt_ll_set_mem_owner(p_rmt_obj[channel]->hal.regs, channel, RMT_MEM_OWNER_HW);
    RMT_EXIT_CRITICAL();
}

Also worth mentioning (although this is really a separate bug) that when mem_block_num == 1 and # of items is large (1200 bytes in this case), occasional flickering occurs, _possibly_ because the ISR is not servicing the RMT peripheral adequately. This is the reason for using 8 mem_blocks, which seemed to fix the flickering. I timed the flickers over a 4 minute period, there's no regularity to them, they occur at random times, sometimes a few seconds apart, other times over a minute apart.

Hi,@cskilbeck
Thanks for reporting this issue, this is a issue introduced by driver refactoring. We will fix it soon.

thanks !!

Great, thanks for looking into it, let me know if you want anything tested.

Having the same issue. I think I'm using version 4.0 but I could be wrong. I would happily apply a patch to the driver so as to not wait for a full version release (in case you already have it).

I haven't looked into it, sorry, just waiting for a new version.

On Sun, 5 Apr 2020, at 4:30 PM, atwoz wrote:

Having the same issue. I think I'm using version 4.0 but I could be wrong. I would happily apply a patch to the driver so as to not wait for a full version release (in case you already have it).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/4959#issuecomment-609434867, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGDOK45D3ORUBVAU2HRCULRLCPZ7ANCNFSM4LO55OJQ.

@cskilbeck @atwoz Thanks for reporting and follow-up, we have a fix which is now under internal reviewing, will update once it is available on GitHub. Thanks.

Hi, @atwoz
release 4.0 do not have this breaking change, Can you check your IDF version?

Hi, @cskilbeck

the fix of this issue will remove the line

length = (off + length) > SOC_RMT_CHANNEL_MEM_WORDS ? (SOC_RMT_CHANNEL_MEM_WORDS - off) : length;

in

static inline void rmt_ll_write_memory(rmt_mem_t *mem, uint32_t channel, const rmt_item32_t *data, uint32_t length, uint32_t off)

Can you help check if this fix is OK?

@atwoz Can you provide you IDF version?

thanks

I'll give it a go and report back.

@koobest I can confirm that the crash goes away when removing that line. Tested on v4.2.

Was this page helpful?
0 / 5 - 0 ratings