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

RISC V ULP does not run in parallel w/ main CPUs (IDFGH-11781) #12876

Closed
3 tasks done
mickeyl opened this issue Dec 27, 2023 · 2 comments
Closed
3 tasks done

RISC V ULP does not run in parallel w/ main CPUs (IDFGH-11781) #12876

mickeyl opened this issue Dec 27, 2023 · 2 comments
Assignees
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@mickeyl
Copy link
Contributor

mickeyl commented Dec 27, 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.2-beta1-263-ge49823f10c

Espressif SoC revision.

ESP32-S3 (QFN56) (revision v0.1)

Operating System used.

Linux

How did you build your project?

Command line with idf.py

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

None

Development Kit.

LilyGo T-Display S3

Power Supply used.

USB

What is the expected behavior?

Since the RISCV ULP is marketed as a co-processor, I would have expected it to be able to run in parallel with the main CPU(s).

What is the actual behavior?

The RISCV ULP starts to run, but halts immediately after a few cycles.

Steps to reproduce.

I have based on the uart_print example, which I modified like that:

void app_main(void)
{
    esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();
    /* not a wakeup from ULP, load the firmware */
    if (cause != ESP_SLEEP_WAKEUP_ULP) {
        printf("Not a ULP-RISC-V wakeup, initializing it! \n");
        init_ulp_program();
    }

    /* ULP Risc-V read and detected a change in GPIO_0, prints */
    if (cause == ESP_SLEEP_WAKEUP_ULP) {
        printf("ULP-RISC-V woke up the main CPU! \n");

    }

    while(true) {
        printf("CPU still running...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }

    /* Go back to sleep, only the ULP Risc-V will run */
    printf("Entering in deep sleep\n\n");

    /* Small delay to ensure the messages are printed */
    vTaskDelay(100);

    ESP_ERROR_CHECK( esp_sleep_enable_ulp_wakeup());
    esp_deep_sleep_start();
}

Debug Logs.

Hello World from ULP-RISCV!
                           Cnt: 0x00000000

More Information.

If I change the example to move into deep sleep, the RISCV-ULP runs forever.

@mickeyl mickeyl added the Type: Bug bugs in IDF label Dec 27, 2023
@espressif-bot espressif-bot added the Status: Opened Issue is new label Dec 27, 2023
@github-actions github-actions bot changed the title RISC V ULP does not run in parallel w/ main CPUs RISC V ULP does not run in parallel w/ main CPUs (IDFGH-11781) Dec 27, 2023
@ESP-Marius
Copy link
Collaborator

Hi,

The ULP can indeed run in parallel, it doesn't require the main processor to be sleeping.

I've ran the example with your changes and I can still see the continuous UART output from the ULP. Maybe there is an issue on the receiving end? Are you able to connect a logic analyzer and see the output?

You could also change the cnt variable in the ULP to be global, and then print this one from the main cpu as well (just to check that the while(1) in the ULP is running)

@espressif-bot espressif-bot added the Awaiting Response awaiting a response from the author label Dec 28, 2023
@mickeyl
Copy link
Contributor Author

mickeyl commented Jan 2, 2024

I have stripped down my example to a very basic one that only toggles a GPIO (connected to a LED). I guess I have been mistaken by problem that a reset indicated by the idf.py flash tool does not reset the ULP core if it is already running.

Now why the UART sometimes suddenly stops receiving data I don't know, but I'll keep poking and will open another bug, if I'm sure there is a problem.

Thanks and sorry for the noise.

@mickeyl mickeyl closed this as completed Jan 2, 2024
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: Opened Issue is new Awaiting Response awaiting a response from the author labels Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

3 participants