ESP32-C6 LP CORE

[JoeSensoric]

I did some tests on the ESP32-C6 and now I'm programming the LP CPU. I managed to run the GPIO and I2C examples and wrote a driver for an AHT20 I2C temperature / humidity sensor.
One use case for me is the LP CPU checking sensor data with some basic processing while the main CPU is in deep sleep mode. In a battery driven system the main CPU would only be started when it comes to enhanced processing or wireless communication.

I use ESP-IDF v5.2-beta1-263 because the C6 support is under progress.

Some questions regarding the LP CPU:

• Will there be ADC access possible from the LP CPU? Table 7-5 in the Technical Reference Manual mentions this. So is only the API missing? In the "ESP32-C6 support status" (https://github.com/espressif/esp-idf/issues/10423) for ESP-IDF v5.1 no LP feature is mentioned.

• The C6 LP CPU is a RISC-V CPU, but it looks different to the ULP-RISC-V CPU used in S2 and S3 (RV32IMAC ISA (instruction set architecture) vs. RV32IMC). Also the API is different. In the announced P6 the LP CPU looks similar, but with 40 MHz and more LP modules like PMU and SPI. Is that correct?

• Is there any way of checking the actual LP SRAM usage? There are only 16 KB available.

[xryl669]

I can't answer all your question since I'm still learning. But I can answer the last one: there isn't any heap on the LP cpu, so the memory usage can't change for the whole duration of the program. You could, theoretically access any byte on the available 16kB address space, but the way the toolchain is built, you'd likely break your program. That's because when you declare variables in your ULP program, the linker will place them in that area on its own chief. If you declare too many variable, it won't link, so you can't overflow the memory. You don't know at compile time the address of the variable (it's only known at link time), so poking in the memory is a very risky gamble, since it can change at each compilation.

I think you're correct for the difference with ESP32 S versions' ULP. It's a shame Espressif doesn't express itself better. Your ULP code will always be target specific, you can't write portable ULP code, since they change the CPU instruction set and feature set for each version of the micro controller.

As for the ADC, technically, you can trigger ADC reading from the LP core (in ESP32C6, I mean), since the LP core can access the peripheral memory (see figure 5.1 in TRM). The ADC peripherals registers are in the 0x6000_E000 to 0x6000_EFFF range (see table 5.2).
However, and that's a big HOWEVER, you'd need to write the code to configure the registers and use them yourself (and I'm not sure it would fit into the 16kB of the LP memory) and you'd need to make sure the peripheral + memory isn't powered down while accessing it.
This means leaving the HP memory powered up, the AHB bus too, and so on.

In the end, I'm not sure it's worth the work compared to light sleeping the HP CPU. That's probably why Espressif didn't took the time to implement it, but if you do it, I would be very interested in power consumption benchmark (and the code if you might publish it).

Hope it helps.

[ESP_Sprite]

The C6 LP CPU is a RISC-V CPU, but it looks different to the ULP-RISC-V CPU used in S2 and S3 (RV32IMAC ISA (instruction set architecture) vs. RV32IMC). Also the API is different. In the announced P6 the LP CPU looks similar, but with 40 MHz and more LP modules like PMU and SPI. Is that correct?

To answer this bit: the CPU architecture indeed changed between the S2/3 and the C6, but as they're still RISCV (the A is for Atomic extensions which the earlier implementation doesn't have) they should still be 99% instruction-level compatible. The P4 is going to have the same core as the C6, just clocked faster.

[JoeSensoric]

Thank you both for your reply!

...
In the end, I'm not sure it's worth the work compared to light sleeping the HP CPU. That's probably why Espressif didn't took the time to implement it, but if you do it, I would be very interested in power consumption benchmark (and the code if you might publish it).

Hope it helps.

My question regarding the LP SRAM usage was motivated by the maximum amount of data to be collected until the main CPU has to be started. But there must be some memory for the return address of function calls?

I see that the ADC is accessible from the LP CORE by low level memory or register access. The code for that is in the ADC lib for the main processor.

But you're right, for me this would be to much work to do.

In general I see not many use cases for the ULP cores. Checking something external and waking up the main processor, or?

I use a "classic" ESP32 with an ULP-FSM program to check an analog value four times a second in a battery driven environment for several years now. In deep sleep mode the current is really low. For the battery usage the external parts on the board are much more relevant than the low power mode of the ESP32.

And of course a C-API for the ULP is much easier to use than the assembler code for the FSM!

...
To answer this bit: the CPU architecture indeed changed between the S2/3 and the C6, but as they're still RISCV (the A is for Atomic extensions which the earlier implementation doesn't have) they should still be 99% instruction-level compatible. The P4 is going to have the same core as the C6, just clocked faster.

Yes, in the ESP-IDF version 5.3 the LP Core examples are marked for C6 and P4, so this seems to be the future API.