Turning off interrupts on core 1

apuder
Posts: 33
Joined: Mon Mar 26, 2018 7:27 pm

Turning off interrupts on core 1

Postby apuder » Thu Jun 06, 2019 9:48 pm

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

WiFive
Posts: 2948
Joined: Tue Dec 01, 2015 7:35 am

Re: Turning off interrupts on core 1

Postby WiFive » Fri Jun 07, 2019 3:56 am

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

apuder
Posts: 33
Joined: Mon Mar 26, 2018 7:27 pm

Re: Turning off interrupts on core 1

Postby apuder » Mon Jun 10, 2019 2:53 am

If I wanted to continue to use NVS API on core 0, would it be OK to call

Code: Select all

spi_flash_guard_set(&g_flash_guard_no_os_ops);
after turning off interrupts on core 1?

ESP_igrr
Posts: 1656
Joined: Tue Dec 01, 2015 8:37 am

Re: Turning off interrupts on core 1

Postby ESP_igrr » Mon Jun 10, 2019 10:16 am

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

apuder
Posts: 33
Joined: Mon Mar 26, 2018 7:27 pm

Re: Turning off interrupts on core 1

Postby apuder » Mon Jun 10, 2019 2:27 pm

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.

User avatar
mad_b747
Posts: 8
Joined: Sun Apr 12, 2020 1:26 pm

Re: Turning off interrupts on core 1

Postby mad_b747 » Wed Jun 03, 2020 4:47 pm

Hi, did you get any progress on that?

apuder
Posts: 33
Joined: Mon Mar 26, 2018 7:27 pm

Re: Turning off interrupts on core 1

Postby apuder » Thu Jun 04, 2020 1:27 am

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

User avatar
mad_b747
Posts: 8
Joined: Sun Apr 12, 2020 1:26 pm

Re: Turning off interrupts on core 1

Postby mad_b747 » Thu Jun 04, 2020 2:15 pm

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

PeterR
Posts: 431
Joined: Mon Jun 04, 2018 2:47 pm

Re: Turning off interrupts on core 1

Postby PeterR » Sun Jun 07, 2020 11:34 pm

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.
& I also believe that IDF CAN should be fixed.

User avatar
mad_b747
Posts: 8
Joined: Sun Apr 12, 2020 1:26 pm

Re: Turning off interrupts on core 1

Postby mad_b747 » Mon Jun 08, 2020 5:29 am

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

Who is online

Users browsing this forum: Baidu [Spider] and 42 guests