Flashing CozyLife LED Ceiling Lamp XT-BL200: Power Supply Challenges

I purchased a random CozyLife LED RGBCW Ceiling Lamp on AliExpress (product page):



I am not entirely sure of its original model name, but the PCB is labeled as XLD-XDFGW-RGBCW1.0:



Opening the lamp is straightforward - just push off the plastic ring surrounding it.

The lamp uses a BL-200 module, which can be flashed without desoldering it from the PCB. The text XDD cozylife 20240829 is written on the shield (see photo further down).

Here is a photo of the backside of the module which shows the text XT-BL200 (WCBGR):


However, I encountered several challenges while flashing due to insufficient power. Initially, when I powered it directly from a UART-over-USB adapter, the device kept appearing and disappearing. My second attempt involved using a power supply from a board included with a breadboard. This provided enough power for the device to connect to my computer, allowing me to read the output (though some text was corrupted). However, when I tried to put the BL-200 into flash mode, the output was entirely garbled. Finally, I resolved the issue by powering the device with an ST-LINK V2, which worked perfectly.

To flash the BL-200 module, you need to solder five cables to the appropriate pins. You can find a detailed image of all the pinouts in this topic. The required connections are as follows:

- TX
- RX
- GND
- 3.3V
- IO8



Next, connect TX and RX to a UART-over-USB converter. To put the module into download mode, IO8 must be connected to 3.3V via a 10k resistor during power-up:


I used the partition TOML and the build file described in this post. Flashing requires Bouffalo Lab Dev Cube, which I configured as shown below:



After flashing, I successfully connected to the device via the AP Hotspot and configured the lamp. I used the OBK template from this post.

The lamp is functional, however, it occasionally becomes unresponsive when displaying certain colors. I need to test further to identify the specific conditions that trigger this issue.

Unfortunately, I did not succeed in dumping the original firmware.

kvakulo wrote:

Unfortunately, I did not succeed in dumping the original firmware.

Are you sure your module is a 1mb version of BL602? If you do the flash ID read it'll tell you the size and ID

>>21478605 Yeah, I thought I had managed to dump the firmware using blflash, but it was just a 1024 kb empty file

The output from flash id read is:

[21:41:24.496] - ========= flash read jedec ID =========
[21:41:24.511] - Read flash jedec ID
[21:41:24.511] - flash jedec id: c2201480
[21:41:24.511] - Finished
[21:41:24.527] - get flash size: 0x00100000
[21:41:24.527] - ========= flash read jedec ID =========
[21:41:24.542] - Read flash jedec ID
[21:41:24.542] - flash jedec id: c2201480

That means 1MB right?

kvakulo wrote:

That means 1MB right?

yes

I have tried to understand in which scenarios that obk crashes, and it seems to be mostly related to mqtt.

If I disable mqtt, then obk is running stable (unless I change colors very quickly through the web interface).

But if I enable mqtt, then obk crashes almost consistently when I change the color through homeassistant, or by simply publishing a mqtt message on the led_basecolor_rgb topic, e.g. publishing the value #fff5b50000:


The log looks like this:


Any ideas of what I could perhaps tweak to avoid this issue?

It took me a while to figure out that the issue was actually caused by the watchdog.

When sending the led_basecolor_rgb command over MQTT, I could make the lamp restart fairly consistently just by sending a hex color a few times, e.g., #000000. Interestingly, this didn't happen when sending the value rand (which sets a random color).

I'm absolutely not an expert in C, so I asked ChatGPT to help optimize the part of the code responsible for parsing the hex string. The optimization it suggested turned out to be enough to fix the issue!

I also increased the watchdog timer, but that alone wasn't sufficient.

You can see the code changes here:
https://github.com/kvakulo/OpenBK7231T_App/commits/speed-up-color-parsing/

It's strange sscanf could be so slow. Maybe original code just crashes and it's not really slow?

I agree, it does sound strange! I looked at that piece of code so many times and kept thinking the issue had to be somewhere else 😅

But I guess sscanf might slow things down just enough to trigger the problem when the command is sent via MQTT. Interestingly, if I sent the led_basecolor_rgb command with hex values through the API, everything worked fine with no crashes.

Anyway, just sharing this as an observation in case someone else runs into a similar issue down the line.

For now, I've deployed the lamp into production, and I'll report back on stability in about a week.

The lamp has been running stably with no crashes for the past two weeks 🥳

I've attached the build with optimized hex parsing in case anyone needs it.