I am trying to track down an issue in a fairly complex application, but the symptom is very odd. The application is a clock, so one thing it does is display the time. It also plays sounds, which it reads from an SD card and streams to I2S using DMA (but it doesn't use the onboard DACs). It maintains an active WiFi connection and it synchronizes time using SNTP.
After some time, the RTC clock slows. The evidence for this is that the time display slows down, the sound output slows down (the music is played slower), the debug that is being output over serial becomes unreadable because the baud rate changes and the WiFi becomes unusable. It is especially a shame that the serial output becomes unreadable. I compiled with core debug and it is trying to output information.
So my question is, what could do this? It seems that the effect is at a very fundamental level to be affecting all of these different functions, so I doubt that any RTOS task could have this effect. Am I wrong?
RTC slows down, affecting DMA and serial output
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: RTC slows down, affecting DMA and serial output
Huh, that almost sounds like your 40MHz crystal is wonky. What hardware do you use? Do you have an idea by how much % the slowdown is? Any power management functions enabled if this is an ESP-IDF app?
Re: RTC slows down, affecting DMA and serial output
I get this on multiple boards, I am using the Pico.
I now think this has something to do with interrupts relating to I2S. If I replace my I2S output code with something that just throws the samples away, there is no problem. If I2S were processing many interrupts, could this have all of the effects noted above? I note that i2s_intr_handler_default() is not exactly a light-weight function.
An additional strangeness is that if I run WiFi in soft AP mode, the problem also goes away. So no I2S is fine, and I2S+Soft_AP is fine, but I2S on its own shows this issue.
I now think this has something to do with interrupts relating to I2S. If I replace my I2S output code with something that just throws the samples away, there is no problem. If I2S were processing many interrupts, could this have all of the effects noted above? I note that i2s_intr_handler_default() is not exactly a light-weight function.
An additional strangeness is that if I run WiFi in soft AP mode, the problem also goes away. So no I2S is fine, and I2S+Soft_AP is fine, but I2S on its own shows this issue.
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: RTC slows down, affecting DMA and serial output
A busy interrupt could impact how everything else that is CPU bound runs, but I'm having a hard time explaining e.g. the baud rate change, as this is something set in hardware. Can I ask what hardware you are using, and would you be OK with sharing code that shows this effect?
Re: RTC slows down, affecting DMA and serial output
How do you know that the baud rate changes? Have you measured the bit rates?
A long time ago I was a little out in my UART clock and this, from time to time, allowed other effects to corrupt (being marginal already). Thing was my configuration was wrong!
On the ESP32 I have seen weird I2C (not I2S) clock stretch issues which have been CPU load dependent. I keep telling myself that I really should have a close look at the ESP bus structure. I think I have seen ESP acknowledge that bus arbitration might effect peripherals (please confirm).
So executing out of cache, using more peripherals etc might explain some things.
Please note that as above - I have not research bus details (so go gentle with me ESP!) but I have seen unexplained I2C clock stretching when using DMA.
A long time ago I was a little out in my UART clock and this, from time to time, allowed other effects to corrupt (being marginal already). Thing was my configuration was wrong!
On the ESP32 I have seen weird I2C (not I2S) clock stretch issues which have been CPU load dependent. I keep telling myself that I really should have a close look at the ESP bus structure. I think I have seen ESP acknowledge that bus arbitration might effect peripherals (please confirm).
So executing out of cache, using more peripherals etc might explain some things.
Please note that as above - I have not research bus details (so go gentle with me ESP!) but I have seen unexplained I2C clock stretching when using DMA.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: Google [Bot] and 95 guests