secure_cert_mfg.py doesn't boot into RAM on ESP32C3

[dbalatoni13]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

The firmware should be loaded into RAM, booted and the utility should get the type of the ATECC chip.

Actual behavior (suspected bug)

If there is no firmware in the flash, the output is the one that I attached.
If there is already some other firmware on the chip, it's loaded instead and the same behavior is seen as described in #15 . The script is treating my custom firmware as if it was the one that was supposed to be loaded into RAM.

Error logs or terminal output

C:\esp-cryptoauthlib\esp_cryptoauth_utility\sample_bins\esp32c3/secure_cert_mfg_esp32c3.bin
Connecting....
Detecting chip type... ESP32-C3
Chip detected
RAM boot...
Downloading 62860 bytes at 3fcb0200... done!
Downloading 492 bytes at 3fcc1440... done!
Downloading 196904 bytes at 40380000... done!
Downloading 28 bytes at 50000000... done!
All segments done, executing at 403802dc
Time required to load the app into the RAM = 5.570646524429321s
Wait for init
Sending version command
fffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff


invalid header: 0xffffffff

...


b'invalid heade\xfeESP-'
ROM:esp32c3-api1-20210207


Build:Feb  7 2021


rst:0x7 (TG0WDT_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)

...

b'invalid header: 0xffff\xf6ESP-ROM:esp32c3-api1-20210207\r\n'
Build:Feb
  7 2021


rst:0x10 (RTCWDT_RTC_RST),boot:0xd (SPI_FAST_FLASH_BOOT)

Steps to reproduce the behavior

1. Set up ESP-IDF v5.5.2
2. Git clone the master branch of this repo
3. Run the command python secure_cert_mfg.py --port COM6 --target_chip esp32c3 --i2c-sda-pin 18 --i2c-scl-pin 17 --type

Project release version

master

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Windows

Operating system version

Windows 10

Shell

PowerShell

Additional context

I pulled straight from the master branch yesterday.

[AdityaHPatwardhan]

Thanks for the issue @dbalatoni13,
May I know about the hardware in this case? Is it the standard ESP32-C3 devkit + ATECC608A/B/C attached via I2C ?

[dbalatoni13]

It's showing the same behavior on my custom PCB and on my ESP32-C3-DevKitM-1 v1.0. It's an ATECC608A attached via I2C with pull-up resistors (2 kOhm) on SDA and SCL.

[AdityaHPatwardhan]

@dbalatoni13 Did you start having this issue on master branch only? Was it working anytime in an earlier version?

May I know if secure boot has been enabled on your device?

[dbalatoni13]

I also tried the commits a59ee4d, 836aa3e, 28fc163 and they behave the same.

I checked and I haven't enabled secure boot.

[dbalatoni13]

Do I have to consider anything about the BOOT and RESET buttons on the devkit when running the script?

[AdityaHPatwardhan]

So the behaviour is clearly related to the BOOT and RESET pins.
We have buttons and then there is also a jumper on the esp32-c3 devkit which allows us to set the boot mode automatically.
The python script does the automatic setting,
Interesting thing is that the first part in your case is succeeding, which puts the chip into download mode and then loads the RAM loadable application into the RAM.
Then the script starts execution.

I am wondering why isn't the chip starting its execution from RAM itself ( which is expected) and instead starting executing from flash where there is no code hence the invalid header error.

[dbalatoni13]

I compiled the firmware for flash execution and this way it somewhat works and I get to another error, I'm going to open a separate issue about it.