ESP32-WROOMESP32D0WDQ5 (revision 1)v4.1-dev-2079-g5dbabae9dxtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0When rmt_config is called with rmt_config_t containing mem_block_num value > 1, then a hard crash occurs in rmt translation function.
Using > 1 mem_blocks used to work (I think on v4.0)
Hang, resulting in WDT trigger
config.mem_block_num = 8;https://gist.github.com/cskilbeck/6ce188fd980637f194f454d5bdd43037
https://gist.github.com/cskilbeck/56da4ad34c9c9bb4d04efe092b5cb632
@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.
Most helpful comment
Hi,@cskilbeck
Thanks for reporting this issue, this is a issue introduced by driver refactoring. We will fix it soon.
thanks !!