Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatible settings for CONFIG_FREERTOS_UNICORE and CONFIG_SPIRAM (IDFGH-10359) #11617

Closed
3 tasks done
derrick-senva opened this issue Jun 7, 2023 · 4 comments
Closed
3 tasks done
Assignees
Labels
Resolution: Won't Do This will not be worked on Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@derrick-senva
Copy link

derrick-senva commented Jun 7, 2023

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.0.2

Operating System used.

Windows

How did you build your project?

Command line with Make

If you are using Windows, please specify command line type.

None

Development Kit.

Custom Board

Power Supply used.

USB

What is the expected behavior?

A 2nd stage bootloader built with single-core mode and PSRAM disabled should be able to boot into application firmware built with dual-core mode and PSRAM enabled.

What is the actual behavior?

The application firmware crashes on an IllegalInstruction.

Steps to reproduce.

  1. Build a bootloader and partition table with ESP-IDF v5.0.2 on an ESP32 with sdkconfig.txt below. The main configuration settings that are in question are CONFIG_SPIRAM is not set and CONFIG_FREERTOS_UNICORE=y.

sdkconfig-original.txt

  1. Build application firmware with the sdkconfig modified as shown in sdkconfig-diff.txt below. The settings that were manually changed in menuconfig are CONFIG_SPIRAM=y and CONFIG_FREERTOS_UNICORE is not set. The rest seem to be automatically updated based on those two.

sdkconfig-diff.txt

  1. Flash all three binaries and reset the ESP32.

  2. Below is the output log from the serial port.

output_log.txt

More Information.

Our project is using multiple components: Secure Boot v2, encrypted flash, encrypted NVS partition, FAT partition, PSRAM, Ethernet, WiFi, lwIP, MQTT, Modbus, and OTA firmware updates. The crash shown above seems to happen very early before it reaches any of our actual application code in app_main().

If the bootloader is rebuilt using the same sdkconfig as the application firmware, the crash does not occur. Incidentally, I noticed that CONFIG_ESP32_ECO3_CACHE_LOCK_FIX=y is added automatically when CONFIG_SPIRAM=y and CONFIG_FREERTOS_UNICORE is not set are configured. Is this related to the issue?

@derrick-senva derrick-senva added the Type: Bug bugs in IDF label Jun 7, 2023
@github-actions github-actions bot changed the title Incompatible settings for CONFIG_FREERTOS_UNICORE and CONFIG_SPIRAM Incompatible settings for CONFIG_FREERTOS_UNICORE and CONFIG_SPIRAM (IDFGH-10359) Jun 7, 2023
@espressif-bot espressif-bot added the Status: Opened Issue is new label Jun 7, 2023
@derrick-senva
Copy link
Author

Hi @KonstantinKondrashov,

Just following up on this issue to see if it's still worth pursing a solution for. Would you agree with the expected behavior described in my original post? Or is there something about the design/architecture of the ESP32/ESP-IDF that would make this an invalid configuration in the first place?

A 2nd stage bootloader built with single-core mode and PSRAM disabled should be able to boot into application firmware built with dual-core mode and PSRAM enabled.

@KonstantinKondrashov
Copy link
Collaborator

Hi @derrick-senva!
There was a similar issue linked with "Unicore bootloader + multi core app" - #10714.
Please try this fix 861a5fb, it should help for your case.

@KonstantinKondrashov
Copy link
Collaborator

Hi @derrick-senva!
Could you confirm that the fix works for your case as well?

@KonstantinKondrashov
Copy link
Collaborator

I close this issue for now. Feel free to re-open if the fix did not help your case.

@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Won't Do This will not be worked on and removed Status: Opened Issue is new labels Jul 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Won't Do This will not be worked on Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

3 participants