ESP32 Forum

Hi. I want to use core 1 to poll GPIO pins in a tight loop. In order for fastest response, I am turning off interrupts on core 1 (read this post for a rationale for doing this: viewtopic.php?f=2&t=10006). Turning off interrupts on core 1 via portDISABLE_INTERRUPTS() and disabling the Watchdog Timer is easy enough. However, this has some nasty side-effects. Some API that runs on core 0 apparently also wants to execute code on core 1 (I believe this is needed for proper synchronization of some API such as writing to NVS). Since interrupts are disabled on core 1, core 0 gets hung when using such API. I can guarantee that core 1 is not using any ESP32 API; only memory-mapped I/O to access GPIO pins. What are my options here to use APIs such as NVS on core 0 with interrupts on core 1 being disabled?
TIA,
AP

I guess you would have to modify the ipc, dport access, and crosscore interrupt features and ensure you aren't violating the dport workarounds.

If I wanted to continue to use NVS API on core 0, would it be OK to call after turning off interrupts on core 1?

Probably not. SPI flash guards are there to guarantee that the other CPU doesn't execute instructions from Flash while the cache is disabled.

Forgot to mention that on core 1 I do not call any ESP-related API; only memory-mapped I/O on some GPIO pins. So I know that core 1 is not doing anything with SPI.

Hi, did you get any progress on that?

unfortunately not. I did a kludgy solution whereby I communicate to the second core via a global shared volatile variable that it should temporarily turn on interrupts. I then do the NVS operations and tell the other core that it can turn interrupts off again. I would prefer a cleaner solution but don't have cycles to look into that.

AP

Thanks for your reply. I will seek if I find some solution on that too myself. If I succeed or partly succeed I let you know as well.

Some ESP drivers/features are core mobile, for example Ethernet features presently lack the ability to be locked onto a core.
The interrupt will be bound to the initalising core however.
So if you initialise your stuff from 'app_main' then interrupts should be bound to core 0.
Not with standing it is possible that initialision starts a task which then registers an interrupt (and so the task might migrate to another core before initialising the interrupt) but I think that would be unlikely as basically that would be 'pants' - to use technical terms.
Even if so you could still forces libraries to behave with an ESP hack. Find the task create and add the core lock parameter.

You do not mention your poll frequency/latency. Perhaps a GPIO interrupt with high priority would work for you OR maybe use the RMT?
Then you could just put your feet up, sip a pina colada & let it all happen? Maybe.

Well, after some hours during last days studying, setting up esp-idf and using code from Mr. Weber Github repo, It seems that it works.
It starts core 0 normally, and set a task to run only on core 1, it ius running an endless testing loop that does a frequency sweep on a GPIO out, I wired it up to a buzzer and the audio is crystal clear - no cracks/interruptions, code seems to be running without any interrupts, task switches, delays or breaks. I´ve done tests as this in the past, and putting a while in between a sequence of for loops was generating a small 'crack' in the audio output to an output port by that time. The slightest discontinuity in the cadency of output of the square wave generated is audible.
Of course in order to trully confirm I must get an oscilloscope however I am far from the place wher I could do such confirmation. I however plan to make tick counts readings - I am printing out on a terminal on a core 0 task along with this core 1 uninterrupted loop, no watchdog breaks also.
Hope this confirms, I plan to use core 1 "bare metal" routines but still have RTOS utilities on core 0...