Using the APP CPU

[BuddyCasino]

I configured usage of the 2nd cpu via make menuconfig, and tried to schedule a task via xTaskCreatePinnedToCore() on the APP cpu. After flashing I was greeted with lots of "unhandled interrupt" errors.

Is there something I must do? Call some initialization routines or something? I couldn't find an example in the esp-idf-v1.0, is the second core not yet supported?

Unfortunately the forum won't let me search for the terms "app cpu", so sorry if this was already discussed.

[WiFive]

Run FreeRTOS only on first core should be disabled (recently made default)
Bootloader output should show app CPU starting
xTaskCreatePinnedToCore last argument should be 1

[BuddyCasino]

> Run FreeRTOS only on first core should be disabled (recently made default)
Check

> Bootloader output should show app CPU starting
Check

> xTaskCreatePinnedToCore last argument should be 1
Check

So its supposed to be that easy? Nothing else to do? I'll try again then. For the record, I also activated "reserve memory for two cores".

[BuddyCasino]

No luck.
This is my main:

Code: Select all

void app_main()
{
    nvs_flash_init();
    initialise_wifi();

    xTaskCreatePinnedToCore(&http_get_task, "httpGetTask", 2048, NULL, 20, NULL, 0);

    xTaskCreatePinnedToCore(&appCoreTask, "appCoreTask", 2048, NULL, 20, NULL, 1);

    ESP_LOGI(TAG, "RAM left %d", esp_get_free_heap_size());
}

This is the task for the APP cpu:

Code: Select all

void appCoreTask(void *pvParameters)
{
    while (1) {
        vTaskDelay(1000 / portTICK_PERIOD_MS);
        ESP_LOGI(TAG, "hello from core no. 2");
    }
}

And this is the boot log:

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0x3ffc0008,len:1832
load:0x40078000,len:3320
load:0x40080000,len:256
entry 0x40080034
I (573) heap_alloc_caps: Initializing heap allocator:
I (574) heap_alloc_caps: Region 19: 3FFD8AE8 len 00007518 tag 0
I (575) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
check b=0x3ffd8af4 size=29948 ok
check b=0x3ffdfff0 size=0 ok
check b=0x3ffe800c size=98276 ok
I (597) cpu_start: Pro cpu up.
I (603) cpu_start: Starting app cpu, entry point is 0x40080cac
I (0) cpu_start: App cpu up.
I (618) cpu_start: Pro cpu start user code
I (642) rtc: rtc v160 Nov 22 2016 19:00:05
I (653) rtc: XTAL 40M
I (810) phy: phy_version: 258, Nov 29 2016, 15:51:07, 0, 0
I (1127) cpu_start: Starting scheduler on PRO CPU.
I (516) cpu_start: Starting scheduler on APP CPU.
tcpip_task_hdlxxx : 3ffdd8b4, prio:18,stack:2048
Unhandled interrupt!
Unhandled interrupt!
Unhandled interrupt!
Unhandled interrupt!

[ESP_igrr]

Could you please try updating ESP-IDF and submodules? "Unhandled interrupt" message was replaced with a more informative one a couple of weeks ago. If you don't want to update, could you please run `make clean` and then build the app again? If I recall correctly, there was a bug that one of FreeRTOS assembly files didn't track sdkconfig.h as a dependency, so it wasn't rebuilt which single core/dual core configuration was changed, leading to similar issues.

[BuddyCasino]

That was it! Thanks a ton.
What is the recommended usage of esp-idf for development at this stage, should I use master branch and update often due to bugfixes?

[ESP_igrr]

Due to a lot of features being rolled out, it is better to keep an eye on the master branch, at the very least. Some APIs will change (or have already changed) between v1.0 and v2.0, so keeping up with the updates may be beneficial. We will release v2.0-rc1 this week, and then v2.0 about a week later.

[BuddyCasino]

Thanks for the quick reply, its much appreciated.
The new SDK is coming along nicely, code quality is so much better than what we had with the ESP8266. Good job!