Open lukecyca opened 6 years ago
Interesting that you see this - I've been seeing a similar problem with my set of five DS18B20 devices on a single one-wire bus, but only when they are on long cables (a few metres each). It'll run fine for a day or two, then crash, but then continue to crash unless manually reset. The thing is, I'm also using a second RMT channel - to gate a signal for frequency counting. I wonder if there's something in the driver that comes to light when more than one channel is in use?
@DavidAntliff thanks for the quick reply! Awesome libraries BTW (I'm using your I2c-lcd1602 one too).
I am using a single DS18B20 on a 3m cable. For me it is not intermittent. It crashes reliably in the same place. I tried adjusting the RMT channels used by each library, to no effect.
Let me know if there are any troubleshooting steps that come to mind. In the meantime I switched to the GPIO version of owb
and everything works great.
@chmorgan actually wrote the RMT driver, so he might be interested in helping us out with this. If you're able to crash it 100% then that could be useful. Does it still crash if the LED strip(s) are not physically connected? If so, perhaps I can run your code on my board and see if I see the same thing?
I wonder if the physical length of the DS18B20 cable causes an issue. Does it crash if you put your DS18B20 on a really short cable (or use a discrete 3-pin device rather than the sealed version?). What if you modify your code a bit to make it attempt to communicate with the DS18B20 even if it's disconnected? What OWB resistor value are you using?
@lukecyca I've seen that those panics don't always point out the appropriate line that caused the panic. In this case rmt.c:769 is the end of rmt_wait_tx_done().
It's certainly possible there is something up in the library. I did take a significant amount of care with the rmt changes, especially around ensuring the structures and structure offset approach was correct but again that doesn't mean there isn't an issue there.
I don't see any usage of rmt_wait_tx_done() in @DavidAntliff's library. Are you calling this function from another section of code not included in your original post? I'm not familiar with that lcd library.
Does it still crash if the LED strip(s) are not physically connected? Does it crash if you put your DS18B20 on a really short cable
I've actually just got 3 discrete WS2812 packages soldered to the PCB (to be used as status indicators). So unfortunately it's not too easy to disconnect them. However, I flashed my code onto a devboard with nothing connected, and I get identical results.
I don't see any usage of rmt_wait_tx_done() in @DavidAntliff's library. Are you calling this function from another section of code not included in your original post? I'm not familiar with that lcd library.
Based on a quick grep, there isn't any call to rmt_wait_tx_done()
from anything in my source tree (either my code or any components I'm using). To my knowledge the only things in my project using RMT at all are this library (ESP32-Digital-RGB-LED-Drivers) and esp32-owb.
If either of you want a copy of my project, I can email it to you. You should be able to flash it to any ESP32 and reproduce this issue. You can find my email on my profile page.
I'm sorry to hear of this problem. I'm not sure what to add to this yet since I've not encountered the problem and I don't have any deep debugging equipment for my devices handy. However, if two different libraries are attempting to manage the RMT peripheral it might lead to a conflict.
I haven't had a chance to test Luke's code yet, however I have noticed today that if some other part of my code crashes (I was causing crashes by deliberately breaking the TCP stack) then some of the time (not always, but quite often) the RMT peripheral driver fails to initialise properly on the next reboot, which then causes subsequent reboots until intervention is made.
So this makes me wonder if it's possible for the RMT peripheral to get caught in a bad state that the init code isn't properly dealing with. Perhaps for this particular issue, one of these two RMT-utilising tasks causes such a state, which the other task then bumps into it when it tries to initialise.
Just speculation at this point though.
I'm currently investigating an issue that affects programs that use more than one RMT channel (which esp32-owb does), and it might be related:
https://github.com/espressif/esp-idf/issues/1815
Try adding this to the very start of the program:
periph_module_disable(PERIPH_RMT_MODULE);
periph_module_enable(PERIPH_RMT_MODULE);
If that prevents the repeated crashing, then it suggests you may be seeing the same problem I'm currently chasing. It's probably not a very good long-term fix though, as it's a bit of a sledgehammer. I'm working on a PR to fix it properly, once I get some feedback from Espressif on the best direction to take.
@MartyMacGyver Has this issue been resolved? I'm running into exactly the same thing...
@pkruger the issue I mentioned on March 28 2018 was fixed by Espressif in 3.0 but may have reared its head again in newer versions. What IDF version are you using? Have you tried the periph_module_disable/enable
workaround?
I was cleaning out old tickets - I've reopened this.
I'm not sure if this was ever resolved in the ESP-IDF - from the perspective of my library there's not much to be done. It is possible to use the system interrupt handler and that might have a positive effect, but it incurs a significant performance penalty (FastLED has implemented that alternative, but again, that assumes this would have an effect on the problem seen - give it a try).
The specific setting is described here: https://github.com/FastLED/FastLED/blob/bbcbb4017ced2f63e521bc1cf7e7b9669da1b1cb/platforms/esp/32/clockless_rmt_esp32.h#L43-L59
Personally, I'd use a DS2482 or similar and let it manage the protocol conversion - using the RMT channels for various purposes at once it tricky at best, especially when doing high-bandwidth operations like driving LEDs.
If I use this library in the same project as esp32-owb by @DavidAntliff, I get the following reboot loop as soon as a hit
digitalLeds_initStrands
.The relevant sections of code are:
I have taken care to specify different RMT channels, and I think the pins I'm using for each peripheral or valid. If I disable one, the other works perfectly.