esp32c6-devkit - uninitialized variable in nuttx/arch/risc-v/src/common/espressif/esp_irq.c

[ppisa]

I am trying Espressif provided ESP32-C6-DevKitC-1 , standard configuration

tools/configure.sh esp32c6-devkit:nsh

even without any configuration change I receive

CC:  common/espressif/esp_irq.c common/espressif/esp_irq.c: In function 'esp_setup_irq':
common/espressif/esp_irq.c:194:6: error: 'cpuint' may be used uninitialized [-Werror=maybe-uninitialized]
  194 |   if (cpuint == ESP_NCPUINTS)
      |      ^
common/espressif/esp_irq.c:156:7: note: 'cpuint' was declared here
  156 |   int cpuint;
      |       ^~~~~~
cc1: all warnings being treated as errors

I can build after quick hack

--- a/arch/risc-v/src/common/espressif/esp_irq.c
+++ b/arch/risc-v/src/common/espressif/esp_irq.c
@@ -153,7 +153,7 @@ static int esp_cpuint_alloc(int irq)
 {
   uint32_t bitmask;
   uint32_t intset;
-  int cpuint;
+  int cpuint = 0;

   /* Check if there are CPU interrupts with the requested properties
    * available.

Please @tmedicci , @eren-terzioglu or somebody other from Espressif team, have you noticed this problem.

[ppisa]

When I look into code then initial value should ensure the fail when the intset is empty, so next change look more logical

--- a/arch/risc-v/src/common/espressif/esp_irq.c
+++ b/arch/risc-v/src/common/espressif/esp_irq.c
@@ -153,7 +153,7 @@ static int esp_cpuint_alloc(int irq)
 {
   uint32_t bitmask;
   uint32_t intset;
-  int cpuint;
+  int cpuint = ESP_NCPUINTS;

   /* Check if there are CPU interrupts with the requested properties
    * available.

But anyway when I compile the Nuttx with above described default configuration, flash it by

make flash ESPTOOL_PORT=/dev/ttyUSB0 ESPTOOL_BINDIR=../esp-bins

then I can see on the serial port on output only

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x40800000,len:0x424c
load:0x40806450,len:0x8e8
entry 0x40803f1e
*** Booting NuttX ***

IROM lma: 0x10000  vma: 0x42000100  size: 0x1c14e
DROM lma: 0x2c14e  vma: 0x42020000  size: 0xaaa8
dram: lma 0x00000020 vma 0x40800000 len 0x424c   (16972)
dram: lma 0x00004274 vma 0x40806450 len 0x8e8    (2280)

and then no more information is printed nor any character is accepted, echoed etc.

[ppisa]

The chip identification is

Chip is ESP32-C6 (QFN40) (revision v0.0)
Features: WiFi 6, BT 5, IEEE802.15.4
Crystal is 40MHz

May it be I have made error that I have flashed bootloader-esp32c6.bin and partition-table-esp32c6.bin according to the documentation page which seems to be deprecated according to other information source.

RISC-V GCC used from Debian stable

riscv64-unknown-elf-gcc (GCC) 11.2.

[eren-terzioglu]

Hi @ppisa,

Our internal tests are building without any problems. Seems you are not using correct toolchain and version. Could you please try to test with suggested toolchain? Output should be like this:

$ riscv-none-elf-gcc --version
riscv-none-elf-gcc (xPack GNU RISC-V Embedded GCC x86_64) 12.3.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ppisa]

Thanks for the response.

I have setup temporarily account, loaded entrusted GCC binaries and compiled actual NuttX sources with added esptool

https://github.com/apache/nuttx.git
https://github.com/apache/nuttx-apps.git
https://github.com/espressif/esptool.git
cd nuttx
tools/configure.sh esp32c6-devkit:nsh
make -j 4
make flash ESPTOOL_PORT=/dev/ttyUSB0

This GCC toolchain does not report evident bug in the code so build goes through, flashing works but there is no output on serial console nor USB serial after power-up. If I press reset button, I obtain

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x40800000,len:0x4378
load:0x40806570,len:0x8d8
entry 0x4080404c
*** Booting NuttX ***

IROM lma: 0x10000  vma: 0x42000100  size: 0x1c23a
DROM lma: 0x2c23a  vma: 0x42020000  size: 0xaa88
dram: lma 0x00000020 vma 0x40800000 len 0x4378   (17272)
dram: lma 0x000043a0 vma 0x40806570 len 0x8d8    (2264)
total segments stored 2

but then the board is stuck. No NSH promp etc. I can test OpenOCD

I hope that bootloader binaries are taken from nuttx/arch/risc-v/src/esp32c6/esp-hal-3rdparty. Because step how to obtain them from https://github.com/espressif/esp-nuttx-bootloader/releases seems to be deprecated in the repository. It is possible that I have done some damage to the bootloader by previous attempt to use there binaries through command

make flash ESPTOOL_PORT=/dev/ttyUSB0 ESPTOOL_BINDIR=../esp-bins

If you think that some procedure how to restore boot, could help, please inform me.

As for the warinig/error 'cpuint' may be used uninitialized, this is real obvious error in the code design. Probably with little effect, because the list is never empty, but it should be corrected. It is bug in the toolchain which you use that it is not reported and it can be reported for different optimization level etc. As for GCC, I use Debian and even my builds of GCC with RISC-V for years, yes there can be some bug and it worth to retest with know to work setup. But use and contribute to NuttX for about 8 years already and we have used it with EP32C3 for years as well. So we have some experience. We can try binaries on the second kit which we have received when I meet with my student working on ICE-V support.

I can send pull to correct uninitialized variable to mainline if the solution to set it up to ESP_NCPUINTS as the mark to fail allocation if the list is empty seems as the correct one to you.

Problem is that we need to decide really soon if we can dare to use ESP32C6 as the target for the microprocessor architectures course starting right now or not. We can use ESP32C3 where in legacy mode we know everything and are able to add peripherals, demonstrate CAN communication with drivers we have contributed into NuttX etc. But we want to use platform with some DC motors and encoder peripheral and motor control PWM of ESP32C6 is promising. We cannot afford to buy 30+ ICE-V kits which would be ideal for many tasks but on the other hand are too expensive to provide to each student and relative complex. I believe we can demonstrate motion control on ESP32C6 even without NuttX drivers by direct code in application which could be even educative how to access and setup MCU peripherals. We show that to our students on our own kits based one Xilinx Zynq SBC. But we need to provide solution for course for foreign university now and want RISC-V based solution to match lectures. I have realized may be 20 or 30 motion control systems on all possible targets from eight-bit MCUs to 64-bit FPGA, PCIe, data acquisition based, GNU/Linux, assembly, NuttX, RTEMS etc. sometimes including own QEMU based matching HW models etc.

But we need at least base OS to work reliably and problem is that we are tight with time now.

[tmedicci]

Hi @ppisa!

First of all, thank you for reporting the issue regarding the non-initialized variable and the outdated documentation. We'll fix this ASAP. We'll be very thankful if you can send the pull-request fixing the non-initialized variable.

About the toolchain, NuttX uses a single toolchain for all RISC-V implementations and that's not different for our Espressif's SoCs. We highly recommend using the same, as we ensure that our SoCs are compatible with these toolchains. You can check it here which toolchain we use and how to download it (or even use NuttX's CI docker image to build NuttX without messing with your local GCC versions). As @eren-terzioglu told you, our internal CI tests the build and the HW, so I can assure you that this configuration is known to be working without any problems (actual NSH commands are tested with HW in the loop).

About the bootloader, it isn't required anymore. NuttX boots directly: no binaries are required. Don't worry if you followed the instructions to download and flash the 2nd stage bootloader, once you re-flash the device with newer NuttX versions, it will be overwritten.

General considerations/recommendations

• In our internal CI we build it with EXTRAFLAGS="-Wno-cpp -Werror". Unfortunately, the current toolchain (Xpack's pre-built GCC 13.2.0-2) didn't trigger the warning, possibly because of the optimization.
• Don't turn off the optimization: stack size is tuned to work with the default optimization level and unintended behavior may happen.
• I highly recommend using the non-legacy version of our boards. Legacy ESP32-C3 will not receive any major updates. On the other hand, support for shared drivers for ESP32-C3, ESP32-C6 and ESP32-H2 are expected to grow faster.

[ppisa]

Unfortunately even even when I have re-build with reference binary from scratch on empty account the board does not work, as I have informed in previous post. So it is not toolchain problem. We try another piece.