After finally taking a vacation, I decided to set up an E3 platform for fun. I wanted to turn it into a server while saving power during idle times. I found an ESP8266 (WeMos D1 R1) that had been collecting dust in my dev board collection, so I used it.

Requirements

1. Control PC power: long press power button, short press reset button, and read power status
2. Receive and log syslog data from COM port
3. Provide serial console functionality
4. Read hard disk LED and buzzer

Requirement 1 is straightforward. Based on Intel's front panel IO design documentation and practical testing, buttons are 3.3V pull-up inputs, while the power LED is a push-pull 5V output. The COM port should technically be RS232 level, but my motherboard (Z270-Dragon) doesn't expose it; instead, it uses a COM_Debug port which happens to be TTL level. Serial console is easiest—the board's CH340 chip directly connects to USB for ttyUSB.

As for requirement 4, I originally planned to implement it, but the hard disk LED is a push-pull PWM 5V output, and the buzzer is a mystery—possibly open-drain. The ESP8266 only has about 5 usable IO pins (despite having many more physical pins, many have special startup requirements). Adding support would require scraping the board and adding voltage divider circuits. Moreover, the hard disk LED isn't essential (who looks at it normally?), and if the buzzer sounds, it indicates a low-level hardware issue that can't be fixed remotely anyway.

Hardware Design and Wiring

First, regarding power supply: all our IO is inside the chassis, so we can directly use 5VSB; of course, where to find 5VSB on the motherboard depends on the specific model. If worst comes to worst, we can route a wire from the ATX connector! We must also disconnect the USB power, otherwise shorting 5V and 5VSB would be problematic.

Next is the voltage level issue for the power LED. It's a 5V push-pull output, so we need voltage division. On this board, the A0 interface has a voltage divider circuit. The ESP8266 receives only 1V. The original design used 104 and 224 resistors to divide 3.3V to 1V. We simply changed it to use 202 and 123 resistors to divide 5V.

Modification shown below:

Next, we can allocate the IO pins:

Also, some ASUS motherboards define COM_Debug like this:

After testing, my motherboard happened to match this definition :smile

Software Design

Interface and Commands

Port 23 is assigned for serial forwarding, and port 22 for the console.

Power control commands use # as prefix and $ as suffix, with the middle character being: R - short reset, P - long press power button, S - short press power button.

Then there's L to list all log files, and codes greater than 0x80 for reading logs by index.

D to enable/disable COM real-time output, M to get current status, V to get version info.

Serial Forwarding

Based on the WiFiToSerial example project, with minor modifications and wrapped in a class.

Since ESP8266 has only one usable receive serial port, we use the swap function to switch pins. When the serial console port connects, we cut off logging and map to USB serial; otherwise, we map to COM.

Logging

Based on LittleFS for chunked log files. The 3MB storage is divided into 64K chunks with over 90 files max, providing some limitation for single-character command reading. Due to LittleFS's power-loss safety design, we must periodically sync to ensure writes are visible. We also handle file size checking and deletion of old files at the same time.

WiFi Management and Configuration

Using the WiFiManager library for automatic WiFi connection and providing a Config Portal on failure. We also register a disconnect event handler to restart the ESP8266.

Afterword

During installation, I discovered that after the system boots, a longer power button press is needed to force shutdown. Also, the signal inside the all-metal chassis was too poor, requiring repositioning, such as near the front panel seams...

Source code available at repository.

1. Insert a new disk, or create a loop device using memory (if it's not large enough, you're out of luck)

2. After lvm, execute the following to remove cache

pvs
pvcreate --norestore --uuid <uuid_of_pv>  /dev/loop0
lvchange -a y vg
lvconvert --uncache vg/lv

3. Remove the disk from vg, then delete the pv created for recovery, then lvchange -ay lvroot
4. Repair the filesystem fsck.ext4 /dev/mapper/vg0-lvroot
5. ^D to exit shell and continue booting, should succeed

I wanted to make a low-power composite macro keyboard and mouse, and I set my eyes on the CH571 chip. I quickly got a development board to work with.

According to the datasheet, the Data area is divided into 16K+2K, which can be powered off at low voltage. Since the RV32 stack grows downward, the original linker script directly placed the stack bottom at the end of RAM, which couldn't meet the requirements.

Starting the Modification

First, let's look at the original linker script

ENTRY( _start )

MEMORY
{
	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 448K
	RAM (xrw) : ORIGIN = 0x20003800, LENGTH = 18K
}

SECTIONS
{

    /* 省略 */

	.stack ORIGIN(RAM)+LENGTH(RAM) :
	{
		. = ALIGN(4);
		PROVIDE(_eusrstack = . );
	} >RAM  

}

Let's modify

Since we need to place specified data at the last 2K location, it's natural to define a custom section, which I'll call (.lram), and specify its address.

Modified linker script:

ENTRY( _start )

__lram_size = 256;

MEMORY
{
	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 448K
	RAM (xrw) : ORIGIN = 0x20003800, LENGTH = 18K
}

SECTIONS
{

    /* omitted */

	.stack ORIGIN(RAM)+LENGTH(RAM) - __lram_size :
	{
		. = ALIGN(4);
		PROVIDE(_eusrstack = . );
	} >RAM  
	
	.lram ORIGIN(RAM)+LENGTH(RAM) - __lram_size  :
	{
		. = ALIGN(4);
		*(.lram);
		*(.lram.*);
		. = ALIGN(4);
	} > RAM 

}

After defining it, define a structure in the source code and add the attribute according to GCC specifications, like this:

typedef struct {
    uint32_t passCode;
    uint8_t rsv[236];

} globalVar_t, *pglobalVar_t; // 256 Bytes max

__attribute__((section(".lram")))
globalVar_t globalVar;

After compiling successfully, I flashed it to the board using WCHISPStudio 3.40 and got a project that keeps rebooting with the indication that the reason is RPOR (real power-on reset).

Debugging the Issue

Searching High and Low

At first, I suspected the stack was corrupted, and I moved the stack address forward by 4 bytes, which fixed it. However, something still felt wrong

As we all know, installing ESP-IDF on Windows is quite difficult with extremely slow compilation speed. Usually, compiling a HelloWorld program takes 5 minutes or more.
However, in practice, ESP-IDF on Linux (WSL) has extremely fast compilation speed. The same HelloWorld program can be compiled in just 10 seconds.

This article mainly introduces the steps for installing ESP-IDF and its VSCode plugin on WSL.

Setting Up Windows Environment

Install Required Software

Required software on Windows:

• Visual Studio Code
• WSL 2
• WSL Ubuntu Distribution (Microsoft Store)
• Python 3.9

Configure WSL

Open a WSL window and execute the following commands to install required packages:

sudo apt update
sudo apt-get install git wget flex bison gperf python3-pip python3-venv python3-setuptools cmake ninja-build ccache libffi-dev libssl-dev dfu-util

Configure VSCode

1. Manually install Remote - WSL from the VSCode Extensions interface (Extension ID: ms-vscode-remote.remote-wsl);

2. Click the green icon in the bottom left corner of VSCode to bring up a similar page, select New WSL Window. A new VSCode window should open, and the green icon in the bottom left should change to WSL:Ubuntu-22.04;
   

3. In the newly opened window, find the Extensions page, search for Espressif IDF, and click the Install in WSL:Ubuntu-22.04 button as shown in the image, then wait for installation to complete;
   

4. After installation is complete, follow the instructions shown in the images to select the download source, change the installation path, click [Install], and continue waiting;
   

Patch ESP-IDF

In practice, at this point we can compile at ultra-fast speed, but we still cannot flash the program. According to the official documentation, we need to install usbipd to map the serial port, but this will encounter permission issues.

Here we utilize a magical feature (bug) of IDF: when flashing, the local PowerShell.exe is called, and naturally, the Python called is also local.
Therefore, we only need to install the corresponding dependencies locally to perfectly solve the problem. Steps:

1. Copy the corresponding files from WSL Ubuntu or download

• ${IDF_PATH}/requirements.txt
• ${IDF_PATH}/tools/kconfig_new/esp-windows-curses

Modify requirements.txt, change the following line (usually at the end)

file://${IDF_PATH}/tools/kconfig_new/esp-windows-curses; sys_platform == 'win32'

to

./esp-windows-curses; sys_platform == 'win32'

Then open Windows Terminal (whichever you prefer), navigate to the saved file directory, and execute

pip install -r requirements.txt

Wait a moment for the installation to complete. (If unsuccessful, try changing the package source)

Testing ESP-IDF Functionality

Open a folder in the VSCode window connected to WSL.
Press Ctrl + E, then press C, select Use current directory, and you can create an IDF project using a template.
Next, connect your development board, select the serial port in the bottom bar at [/dev/ttyUSB1]; then compile and flash (click the 🔥 icon to do both in one step)

After a moment, you will be able to see logs from the serial port monitor!

All Done!

Now you can enjoy blazingly fast 10-second compilation and flashing!

This month I suddenly had the idea to make a keyboard and mouse simulator, so I went to the familiar WCH website and found the CH552G and CH340K.
Without further ado, let's get started. (At this time I didn't realize I was stepping into a big pit, because there's already a ready-made CH9326 chip)

Schematic Design & PCB Design

First, let's look at the schematic:

The overall idea is to use CH340K as a USB-to-serial converter to connect with CH552, where CH552 emulates an HID device and sends HID packets to the controlled host according to commands received on serial port 0, completing the simulated operations.
In the diagram, I connected the serial port RTS and DTR to the interrupt pins of CH552 for flow control. SRV05 is an ESD protection chip. (Why did I only think about this when winter came...)

As for the PCB, I quickly drew a two-layer board and sent it to JLC for prototyping. (Then I got into trouble soldering the MicroUSB connector)

Firmware Development: Not yet successfully soldered, lacking motivation

As we all know, resource files play an indispensable role in program execution. However, to achieve cross-platform resource file utilization, we must abandon Win32 resource files. This article introduces a method for generating and embedding resource files using the (MinGW) GCC toolchain.

Step 1: Generate Resource Object Files Using ld

In this step, we will use the linker (ld) to generate the resource object file (.o) we need.

Prepare Resource Files

Resource files can be in any format, including but not limited to images and text files. Here we use two text documents as examples:

File: a.txt

dawdawwdwkjagcbsfgbcfgfjbkajkaadgad

File: b.txt

Hello,txt1!

Generate Resource Object File

Open CMD in the folder containing the resource files and execute:

ld -r -b binary a.txt b.txt -o res.o

Thus, we obtain the resource object file res.o.

Check Resource Object File Symbols (Optional)

To ensure successful compilation, we can first check the symbols exposed by the resource file to understand the naming pattern.

Execute in the CMD:

objdump -x res.o

We get a large amount of output. At the end of the output, there is a table similar to:

SYMBOL TABLE:
[  0](sec -1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000023 _binary_a_txt_size
[  1](sec -1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000000000000000b _binary_b_txt_size
[  2](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x000000000000002e _binary_b_txt_end
[  3](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000023 _binary_b_txt_start
[  4](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000023 _binary_a_txt_end
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 _binary_a_txt_start

This shows that our text documents are embedded in the resource object file, generating several symbols. We can summarize the pattern:

Step 2: Write Test Code

Importing Symbols

Our ultimate goal is to embed the resource file into the executable and use it in the program. To achieve this, we need to import symbols in the source file, for example:

extern const char _binary_a_txt_start[], _binary_a_txt_end[];
extern const char _binary_b_txt_start[], _binary_b_txt_end[];

By using the extern keyword and copying the symbol names, we can import symbols into our source code.

Using Symbols

For example:

int main(){
    size_t a_len = _binary_a_txt_end - _binary_a_txt_start;
    size_t b_len = _binary_b_txt_end - _binary_b_txt_start;
    printf("a.txt len=%u,content= %.*s\n", a_len, a_len, _binary_a_txt_start );
    printf("b.txt len=%u,content= %.*s\n", b_len, b_len, _binary_b_txt_start );
    return 0;
}

Save as test.cpp and compile:

g++ res.o test.cpp -o test.exe
The executable file is now generated. The execution result should be:

a.txt len=35,content= dawdawwdwkjagcbsfgbcfgfjbkajkaadgad
b.txt len=11,content= Hello,txt1!

## Step 3: Encapsulate for Easy Use
Here we use GCC's macro expansion feature to write example encapsulation code:

File: customResource.hpp
```Cpp
#pragma once
#include <cstdint>

#define RESDEF(name) extern const char _binary_##name##_start[], _binary_##name##_end[]
#define RES(name) _binary_##name##_start, _binary_##name##_end

namespace Utils {
class Resource {
public:
    Resource(const char* begin, const char* end)
        : _begin(begin)
        , _end(end)
    {
    }
    ~Resource() { }
    const char* begin() { return this->_begin; }
    const char* end() { return this->_end; }
    size_t length() { return this->_end - this->_begin; }
    const uint8_t* data() { return (const uint8_t*)this->_begin; }

private:
    const char* _begin = nullptr;
    const char* _end = nullptr;
};

}

File: main.cpp

#include <cstdio>
#include "customResource.hpp"

using namespace Utils;

RESDEF(a_txt);
RESDEF(b_txt);
Resource a(RES(a_txt));
Resource b(RES(b_txt));


int main()
{
    printf("a.txt len=%u,content= %.*s\n", a.length(), a.length() , a.begin());
    printf("b.txt len=%u,content= %.*s\n", b.length(), b.length() , b.begin());
    return 0;
}

Compile and run as usual.

Postscript

This article references the following blog posts:

Adding Resources in GCC

Detailed Discussion of #define Replacement Rules and # and ## in Macro Definitions

ld Parameter Explanation

Written after testing on Windows 11 + MinGW-w64 11.2.0 Seh. Thanks to the original blog authors!

I was able to use CDN to accelerate access speed. Everything went smoothly after using CDN, until one day when I checked the CDN logs and found that the origin error rate had surged dramatically.

Analysis of the Cause

First, I accessed my own website and found that while the page could display, all styles and buttons were gone. When I opened the developer tools (F12), I saw many 403 errors. No wonder the origin error rate was so high.

Then I thought maybe the origin server was hacked. However, the origin server is also a static site, so there was no possibility of it being attacked. Direct access to the origin also showed it was normal.

At this point, I had already guessed it was a DNS pollution issue. That is, the origin address that the CDN server obtained was rewritten. To further verify my guess, I contacted the CDN provider. After their test, using virtual machines from various locations to access the origin, they found that the results were incorrect in certain provinces (redirected).

At this point, DNS pollution was confirmed.

Resolving the Issue

Since it was polluted, the solution was simple: just replace the origin domain with an unpolluted domain. Although there was still a risk of pollution, we could enable DNSSEC to prevent DNS pollution to some extent.

I thought a kernel module crash caused a kernel panic and spent hours troubleshooting. Finally, I found this blog post and discovered the issue was PCIE changes causing the network interface name to change. So I modified netplan to:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true
    enp2s0:
      dhcp4: true
    enp3s0:
      dhcp4: true
    enp4s0:
      dhcp4: true
    enp5s0:
      dhcp4: true

Restarting solved the issue! After logging in, I found it was now running on enp1s0!

Edit: You can actually use netplan's MAC match feature to specify the interface, which effectively solves these issues.