successful build and flash of esp32-c6-devkitc-1

I managed to order three of the ESP32-C6-DevKitC-1 developer boards from the Espressif store on Amazon. They’ve been advertised since mid-2022, and where-ever I went to try to buy them, they were advertised as out of stock. Finally I stumbled onto them on Amazon, and grabbed three examples. They arrived at my home earlier this week. They had to wait until today before I could sit down and begin to work with them.

These are not supported in any existing release of Espressif’s ESP-IDF. I had to clone from the master, or trunk, of their GitHub repo. This is what I used to perform that clone:

git clone --recursive https://github.com/espressif/esp-idf.git esp-idf-main

Once cloned I installed the ESP-IDF software and enabled the development environment I then moved into my wifi-scan folder that I’d migrated to ESP-IDF V5, and ran the following:

idf.py --preview set-target esp32c6

You have to run --preview for everything to be properly set up for the build. After that you can run a regular idf.py build, followed by the flash and monitor commands. You will need to do this before the boards will work. Out-of-the-box the boards, when powered up via USB-C, will immediately go into an endless boot loop because they’re flashed with the wrong code.

Here’s a small portion of what I saw on successful boot after a successful flash.

...
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:0x4086c510,len:0xd3c
load:0x4086e610,len:0x2a64
load:0x40875720,len:0x1790
entry 0x4086c510
I (23) boot: ESP-IDF v5.1-dev-3462-g045163a2ec 2nd stage bootloader
I (24) boot: compile time Feb 17 2023 13:48:04
I (24) boot: chip revision: v0.0
I (28) boot.esp32c6: SPI Speed      : 40MHz
I (33) boot.esp32c6: SPI Mode       : DIO
I (38) boot.esp32c6: SPI Flash Size : 2MB
I (42) boot: Enabling RNG early entropy source...
W (48) bootloader_random: bootloader_random_enable() has not been implemented yet
...

Here’s some interpretation of those output lines. Line 2 shows that it’s an ESP32-C6 due to the boot ROM on the chip. Line 11 says it was built with ESP-IDF v5.1-dev. I cloned that specific tag, but it won’t support ESP32-C6. You have to use master. I found that a little concerning as the README says that ESP-IDF v5.1, when it’s formally released, is supposed to support the ESP32-C6 device. Oh well.

Everything else seems to be behaving normally, especially support for C++20 in the tool chain. This chip is also supposed to support Zigbee, but I haven’t researched that bit yet. Another goody to check out later.

an adventure using ssh with github — the finish

In the post immediately before this, I wrote how I’ve started using the Yubico 5 Series key, how I created an SSH key pair using it, and how I managed to put the public key portion up in my account. The next step was to migrate one of my local project repos from HTTPS and username/password authentication to SSH and public/private key authentication.

Migrating the Repo

The command used to migrate a repo from HTTPS to SSH is git remote set-url origin git@github.com:[Username]/[Projectname].git, where Username is the email username you’ve used in your GitHub account, and Projectname.git is the, yes, project name of the repo you want to change. Because I have a number of projects in my account, I decided I wanted to automate this process. To that end I wrote a simple five line shell script to handle this.

#!/usr/bin/env bash
git remote set-url origin $(\
git remote show origin | grep "Fetch URL"\
 | sed 's/ *Fetch URL: //' \
 | sed 's/https:\/\/github.com\//git@github.com:/')

I am not a master of either sed or regular expressions, and every time I choose to use these tools I go slowly and test my scripts every step of the way. When I started to develop this script I started with line 3 and tested each single line as it was added to the complete chain before adding the next line in the sequence. When I was satisfied the transformation was correct I wrapped the lines in parenthesis and added line two to complete the script. Let’s go over this script line by line.

1. This is my usual bash shebang that I always put at the top of my scripts.
2. This is the git command that will change the URL, and it’s the last command to be executed in the sequence, although it’s counter-intuitively the first command listed.
3. This is the line that shows the repo’s origin, and we’re grepping for Fetch URL for the critical information we will need for the commands to follow.
4. This is the line that uses sed to remove the leading text to Fetch URL, replacing all those characters with nothing, thus deleting it.
5. The now-leading https://github.com is replaced with git@github.com:. The part of the Fetch URL that contains your username and projectname remain unchanged in the final string.

The parenthesis on lines 2 and 5 wrap the results of all that editing and pass it back as a single argument to the git command on line 2 of the script. Then the script finishes executing and we’re done.

Testing the Migration

The script, if it runs successfully, runs silently. To check that the migration was successful, you need to run the git command again to show the origin information.

~ git remote show origin
* remote origin
  Fetch URL: git@github.com:wbeebe/qt6.git
  Push  URL: git@github.com:wbeebe/qt6.git
  HEAD branch: main
  Remote branch:
    main tracked
  Local branch configured for 'git pull':
    main merges with remote main
  Local ref configured for 'git push':
    main pushes to main (up to date)

When you run this command you need to be near the Yubico key, with the circled logo facing up. That’s the touch sensor that allows the key to work. When you execute the git command the Yubico key logo will start to flash. Put your thumb (or whatever digit you used to set up the key’s touch ID) over the flashing logo and the command will successfully execute as it did here. Now when I push up to GitHub, I have to touch the key for it to fully succeed. I was able to finally push my tag up to qt6.

At this point I now have full command line git control again. I will probably continue to use GitHub Desktop as it has some nice features wrapped up in the tool, but for plain old development and repo synchronization I can go back to what I was doing previously, without GitHub Desktop. For those who think this is too much effort, think again. I don’t think anyone wants to target anything I’ve got on GitHub, but you never know. I want my GitHub account locked down as tightly as reasonably possible, and this provides that feature. I’ll go the extra effort for security.