The story of how "this should only take an hour" became a month-long open source project.
How It All Started
In my spare time, I build my own smart home devices. Not because there aren't any good products on the market. I simply don't like closed ecosystems, their dependence on cloud services (especially), and sometimes even mandatory subscriptions.
So I build things for myself — things that are actually convenient to use. It's no longer the kind of DIY project you throw together from whatever happens to be lying around in a drawer, with wires everywhere. But it's not mass production either. Just devices that solve my own problems and work exactly the way I want them to.
For one of my battery-powered sensors, I chose the E18-MS1 Zigbee module based on the CC2530. Simply because it's available and cheap. Writing firmware for it wasn't particularly difficult. There are plenty of existing projects you can adapt to your own needs. Getting that firmware onto the chip... turned out to be a completely different story.
Since I already owned several programmers, including a J-Link, I never even considered buying the official TI CC-Debugger. But it quickly became obvious that there was no way to flash the module without one.
Buying a proprietary programmer just for a single project didn't make much sense. So, like most developers in that situation, I started googling for alternatives.
I found one.
Or at least, I thought I did.
There weren't many options. Just a handful of ESP32-based projects, most of them abandoned by their authors years ago.
The first one seemed to work, but couldn't reliably flash the entire firmware. The second one didn't even detect my chip. The third one... turned out to be an AI hallucination. Yes, that's a thing now.
One project looked like exactly what I needed. It claimed full support for my chip. The author said he was using it successfully himself, and the source code was available as open source. All I had to do was compile it.
Well...
I was almost certain all that was left was to adapt it for my module.
It Didn't Work.
The problem wasn't my chip. There was no way three modules, bought from different stores and different production batches, were all defective.
The first few days were spent simply trying to understand someone else's code. I wanted to figure out why it didn't work for me when the author clearly stated that the project was fully functional. Sure, I was porting it from the ESP32-S3 to the ESP32-C3, and I knew that would require some changes. But I certainly didn't expect that the real problem had nothing to do with that.
At first, as it usually goes, I was looking for that one bug. It felt like fixing one function would make everything work. Then another one...
It didn't.
The deeper I dug into both the code and the Texas Instruments documentation, the more inconsistencies I found. The project had been written for an earlier generation of chips. Some TI Debug Interface commands behaved differently, the timing didn't match the documentation, and some mechanisms required for reliable operation simply weren't there.
At that point, I realized I had two choices.
The first was to keep patching someone else's code, adding more and more workarounds.
The second was to spend more time now, but build a foundation that I would completely understand.
I chose the second.
One Module at a Time
If I was going to rebuild it anyway, I wanted to do it properly. Or, as my father used to say:
"Do it well. Doing it badly will happen on its own."
I've never been a fan of magic hidden under the hood, so moving to ESP-IDF felt like the obvious choice. Even if it meant replacing almost the entire codebase.
I decided to start with the Low-Level layer. If the problem was down there, there was no point building anything on top of it.
The first step was understanding the TI Debug Interface itself. Not someone else's implementation, but the Texas Instruments documentation. Line by line. Command by command.
Little by little, I started finding things that explained the project's strange behavior. Incorrect timings. No mechanism for waiting until the chip was ready. Commands that didn't behave the way the documentation described. Wrong registers...
Eventually, the first fixes paid off.
First, the chip simply responded.
Then I managed to execute the first commands.
Then I was finally able to read its memory.
Each step made it possible to verify the next one. Gradually, it became clear that replacing the old implementation would be easier than trying to fix it.
That was the moment it stopped being "just a small fork."
Then Came the "What Ifs"
I could have stopped there. The firmware was flashing, the chip was responding, and my original goal had been achieved.
But once you know the code well, it's very hard to resist the thought:
"Why not add just one more thing?"
And that's how new features started to appear.
The first one was support for Intel HEX firmware. That's the format most custom firmware for these chips comes in.
Then came the ability to read complete chip information, extracted from the internal registers and presented directly on the main page.
Then a dedicated Settings page, where the programming pin assignments could be changed directly from the web interface, without touching the firmware.
Later came real-time register access, light and dark themes, a mobile-friendly interface, a Ukrainian translation...
And finally, the ability to use the project without compiling anything. Just flash the prebuilt firmware for the ESP32. No drivers. No extra software. Just a web browser. Even on a phone.
Most of those changes weren't strictly necessary. But I wanted to build a tool that would be convenient not only for me. I already knew how everything worked and could live with small inconveniences. The next person shouldn't have to go through the same journey, so I tried to make everything as intuitive as possible.
By then, it had become a completely different project.
Why I Open-Sourced It
What started as an attempt to flash a single module eventually grew into a standalone project with documentation, prebuilt firmware, and the ability to use it without installing any additional software.
At that point, a simple question came up.
Should I keep it to myself, or release it as open source?
For me, the answer was obvious.
There's a saying I've remembered since childhood:
"Do good and throw it into the water."
I don't know if this project will be useful to anyone else.
But if even one person doesn't have to go through the same weeks of trial and error that I did, then all of this was worth it.
In the end, the whole journey took almost a month: a few days to understand someone else's code, about three weeks of rewriting, and another week writing the documentation.
That journey became ESP32-CC-Tool.
The project is available on GitHub:
ESP32-CC-Tool
Top comments (0)