Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when RMT mem_block_num > 1 (IDFGH-2915) #4959

Closed
cskilbeck opened this issue Mar 19, 2020 · 13 comments
Closed

Crash when RMT mem_block_num > 1 (IDFGH-2915) #4959

cskilbeck opened this issue Mar 19, 2020 · 13 comments

Comments

@cskilbeck
Copy link

cskilbeck commented Mar 19, 2020

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

@github-actions github-actions bot changed the title Crash when RMT mem_block_num > 1 Crash when RMT mem_block_num > 1 (IDFGH-2915) Mar 19, 2020
@Alvin1Zhang
Copy link
Collaborator

@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.

@koobest
Copy link
Contributor

koobest commented Mar 19, 2020

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 !!

@cskilbeck
Copy link
Author

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();
}

@cskilbeck
Copy link
Author

cskilbeck commented Mar 19, 2020

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.

@koobest
Copy link
Contributor

koobest commented Mar 20, 2020

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

thanks !!

@cskilbeck
Copy link
Author

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

@atwoz
Copy link

atwoz commented Apr 5, 2020

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).

@cskilbeck
Copy link
Author

cskilbeck commented Apr 5, 2020 via email

@Alvin1Zhang
Copy link
Collaborator

@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.

@koobest
Copy link
Contributor

koobest commented Apr 7, 2020

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

@koobest
Copy link
Contributor

koobest commented Apr 7, 2020

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

@cskilbeck
Copy link
Author

I'll give it a go and report back.

@3miliano
Copy link

3miliano commented May 5, 2020

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

@igrr igrr closed this as completed in 0bf2906 Jun 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants