[BL2028N/BK7231M] Flashing Dogness D07 (Belon Chip) - Boot Issues

Hi Everyone,

I have a curly one, and I have spent a lot of time on this with little success so far but have a bunch of information as a result of my tinkering, I get the feeling the issue I'm having is its not a Tuya device so the partitions are in the wrong please, I have tried taking a look at the binary dump in Ghidra but I'm no firmware reverse engineer. Any help would be appreciated! Even if its to tell me its not possible so I know to stop

I have uploaded the firmware dump in the attached zip.

Flashing results in it not booting from what I can tell, both tx\rx lines display only "□" each time i perform a reset

Have Tried the following
* Flashing several versions of openbeken for BK7231N
* Flashing a Tuya backup from another basic device, then flashing OpenBeken firmware.
* Have been able to flash back to original firmware each time and it seems to be happy again.

Flash information: mid: 1560EB, icName: TH25Q_16HB, manufacturer: TH, szMem: 1000000, szSR: 2, cwUnp: 0, cwEnp: 7, cwMsk: 407C, sb: 2, lb: 5, cwdRd: 05-35-FF-FF, cwdWr: 01-FF-FF-FF
Entering SetProtectState(True)...
sr: 4
sr: 4004
final sr: 4004
msk: 407c
cw: 0, sb: 2, lb: 5
bfd: 0
sr: 0
sr: 0
final sr: 0
msk: 407c
cw: 0, sb: 2, lb: 5
bfd: 0

Some of the serial output from alt set of tx\rx pins when dogness firmware loads.
R0:0x00800000R1:0x00000000
R2:0x005AA000
R3:0x00000006
R4:0x00400001
R13:0x00401C1C
R14(LR):0x000033AC
ST:0x00000000
[I/FAL] Fal(V0.4.0)success
[I/OTA] RT-Thread OTA package(V0.2.4) initialize success.


go os_addr(0x10000)..........
0
prvHeapInit-start addr:0x40ff70, size:131216
[Flash]id:0xeb6015
[Flash]init over
sctrl_sta_ps_init
SDK Rev: 3.0.46
[THD]app:[tcb]411250 [stack]410248-411248:4096:5
[THD]extended_app:[tcb]411ac0 [stack]4112b8-411ab8:2048:4
[THD]idle:[tcb]411f30 [stack]411b28-411f28:1024:0
[THD]timer_thd:[tcb]412cb8 [stack]4120b0-412cb0:3072:2
OSK Rev: F-3.0.28
cset:0 0 0 0
/********flash_get_addr*******/
read addr:1fd000
00 99 33 41 0b 8d
bandgap_calm_in_efuse=0x3c
[load]bandgap_calm=0x20->0x1c,vddig=4->5
[FUNC]rwnxl_init
chip id=7231c device id=20521028
IP Rev: W4-3.0.46-P0
txdesc flush
[FUNC]intc_init
[FUNC]calibration_main
get rfcali_mode:1
device_id=0x20521028

Device purchased here, for specs etc
https://www.pbtech.co.nz/product/PETDON0003/D...ss-D07-Smart-18L-Fountain-Smart-Pet-Water-Dis

Also found a copy of the Belon Writer V1.55 if anyone wants it, it seems to only have write not read, does have compare though

All the images I have taken, would be keen to know if anyone has a good place to get a cheap bdm frame or similar, I like the look of PCBite probe kit but its too expensive for my use cases.

Usual problem is power.
How do you power device after flashing? Serial adapter probably doesn't have enough current capability. You need to power it from an external regulator or from the original source.
Also log in Beken firmware on BK7231T comes from TX2/RX2 uart. That's different from the one used for flashing. Which one are you trying to use?

This device has different bootloader, in case based on RT-Thread. This requires some work on development. Maybe an unencrypted binary would work or binary encrypted with different keys. Not sure about the firmware start offset. Similar issue has been already on forum but wasn't addressed because it seems to be very rare so far...

wouldn't flashing full binary replace bootloader? Or is it somewhere else?

>>21096055This is good suggestion, I did think of this though, apologies I forgot to add this to the post, it was actually one of the last things I tried before posting this, powered it off the normal power supply.

It also posts while attached to the serial adapter with its stock firmware which is how I got the logs from the other serial pins.

Try flashing 2MB binary full of 0x00 bytes and you will see that RT thread message persists. Bootloader is... somewhere outside on N.

Oh that's a shame, I imagine this is something that's already been investigated? As at this point I'm up for more risky options and flashing a new bootloader seems like fun 😊 

Is there anything I can check allow me to create a custom binary?

I also considering that I could transplant bk7231n from another device, I have a bunch of rf blind controller I picked up on clearance that either have an N or T, haven't checked which as yet will be one or the other though.

The other item is I know from ghidra that the firmware layout is quite different from tuya devices, this isn't likely to affect anything? Was kinda thinking given I flashed another devices tuya stock firmware this likely would rule that out though as I tried flashing openbeken after that which resulted in the same boot issue.

Have been able to get it working with some massive help from the lovely people working on LibreTiny

The main component of the solution was from one of the cloudcutter team on their discord and then help from the lead Dev, thank you both!

Created a config in ESPHome on my HA server which I was able to use to generate a uf2 then flash the device with it using ltchiptool

I was then able to write the LibreTiny kickstart OTA as and get that going, which is an option I will explore as I already have a bunch of other ESPHome devices. I did have some issues with the device not connecting to WiFi but was able to resolve this with the Restore RF part in Easy UART flasher.

For completeness though I also did the same again but flashed the latest openbeken OTA and have been able to get that going, I did however have some different WiFi issues where the standalone AP doesn't let you browse to the web server, Restore RF part didn't work in this case but I worked around by setting the WiFi AP settings in Easy UART Flasher and using the Write only OBK config.

Obviously this isn't an ideal way to get this device booting and mostly working but gives me a way to start working on the module config for either LibreTiny or OpenBeken

I have attached a working dump, that I removed WiFi settings from, so anyone who wants to use it will need to write new ones from Easy UART Flasher at this stage

Would be keen to know if this can be used to add better support for Dogness devices, I have also attached the SPI dump I took using ltchiptools SPI addon

P.S. if you live in NZ or AU I caution buying the FT232RL based duinotech USB to serial adapter (XC4594) from Jaycar, its junk especially for the price the 3.3/5v select switch doesn't work it just outputs 5v either way, I'm lucky I didn't let out the magic smoke...

So they just use 0000 as encryption key? Well that certainly wouldn't be hard to guess.
So I need to change key here:

@terryb8s are you willing to help me testing that so we can add those binaries to OBK builds?

Added after 1 [hours] 3 [minutes]:

i attached my binaries so you can try

>>21103347 Sure no problem, will test it in a moment and send back the result.

Hopefully it will work soon, maybe not on the first try, but we will see... do we also need to change the flash address?

Btw, in your binaries, which OBK version is it? Maybe I could try downloading and comparing it against my builds... but I would need to know which version you have exactly. Hmm

>>21103729 Flashed the QIO bin from the zip you attached, result seems to be not booting, I have serial attached to the P0/P1 UART2 along with another for flashing via UART1 and only get something similar to □, rather than full boot, no AP, this was flashed from 0x0 by the looks of Easy Flasher output.

I can try with an offset if you like, I guess with ltchiptool? is there a way to do this with easy flasher, a hidden feature to load a file and set offsets?

Build I used for OTA in the dump I attached was OpenBK7231N_1.17.601.rbl

Maybe you can use our QIO but keep (or overwrite) with their original bootloader, can you try? I will investigate it more in the morning (it's late night here in my country).

Tried flashing the QIO bin with ltchiptool at offset 0x11000 and same for skip offset for input file, no boot, reset it to factory image then also tried rbl at 0x132000, no boot (didn't think this would work)

Added after 3 [minutes]:

link to LibreTiny discord post if anything in there helps too, though I think I have posted most of the info here.
https://discord.com/channels/967863521511608370/1246228719593328681

sorry Its mid morning here, its all good I can wait as I can't work on this much longer till tonight anyway

AES keys seems unchanged so I need to investigate more:

I have tried flashing OpenBK7231N_App_QIO_1.0.0.bin starting at 0x0 and no skip offset but no OBK and no boot log.

Also tried going back to factory, which worked, then flashing OpenBK7231N_App_UA_1.0.0.bin from 0x1000 with no skip offset but no success either

This was using this Matter device with 1.0.13 bootloader and seemingly no encryption

https://www.elektroda.com/rtvforum/topic4032988.html

Added after 4 [minutes]:

here's a dump of the efuse for the Matter device if that's of any help investigating

Got it working this morning :)

Performed full erase.

Flashed 0x0 to 0x10000 from factory goodness backup

Flashed starting 0x10000 the OpenBK7231N_QIO_1.0.0.bin provided

Had to do RF restore to get AP working.

Not sure if the image is cut down in any way pwn seemed to not work on P7 which was working previously.

I also see an error before it starts the OS about OTA

I see, so in order to add support of that to our builds, I need construct a binary from 0x0 to 0x10000 your bootloader, then with OBK data?

Why was restore RF required? Or maybe... maybe it makes sense, if this has totally different firmware, then RF partition was not present at all?

Did you do restore RF on your first OBK attempt?

I need to compare original 2MB dump with our RF patition to know what's there.

Thinking the OTA error is because of my full erase, so nothing will be there based on the memory map, correct?

BK7231N:

Name	Code	Start	Length
Bootloader	BK_PARTITION_BOOTLOADER	0x00000000	0x11000 //68KB
Application	BK_PARTITION_APPLICATION	0x11000	0x121000//1156KB
ota	BK_PARTITION_OTA	0x12A000	0xA6000 //664KB
RF Firmware	BK_PARTITION_RF_FIRMWARE	0x1D0000	0x1000
NET info	BK_PARTITION_NET_PARAM	0x1D1000	0x1000

Added after 6 [minutes]:

>>21105156 Yes I believe i did do a RF restore as was having issues with wifi in with ESPhome

The SPI dump will have the original RF

The working version with original bootloader to 0x10000 and QIO image from 0x1000 this morning would not have had RF as I did full erase before I started.

terryb8s wrote:

Thinking the OTA error is because of my full erase, so nothing will be there based on the memory map, correct?

won't OTA fail because it's at 0x132000 like T and not at 0x12A000 like N

Doing full erase will indeed also erase RF partition, which is later not affected by flashing OBK. So that's why you had to restore RF manually?

>>21105163 yes that would be the case as I said it erases first so would be nothing there.

Yes had to do RF restore as the MAC ended with 000000 and AP mode wasn't working as a result.

Just now replicated the same full erase then original bootloader, then your QIO image, then also restore RFNet data and I get the following. (see below: WARN: TCPIP mutex is NOT locked)



Added after 54 [seconds]:

>>21105162with my full erase I think it's likely because nothing was there.

I don't know what kind of mystery is going on in that RF partition, but I was aware that in some rare cases doing my "restore RF" fixes broken WiFi. That being said, I had some devices with broken RF (MAC ending with 00 00 00) and they still had WiFi working, except for the MAC duplicate issue (with cleared MAC, both devices had the same MAC, ending with 00 00 00).

Anyway, it's again late night in my country, so (hopefully) tomorrow morning I will try to replicate what you said in the build script and add binaries to main releases...

Added after 1 [minutes]:

I can see that there is our bootloader here:
https://github.com/openshwprojects/OpenBK7231...r/platforms/bk7231n/bk7231n_os/tools/generate
So I will have to paste dogness boot here and adjust script to support both versions...

Added after 1 [minutes]:

https://github.com/search?q=repo%3Aopenshwpro...%2FOpenBK7231N%20bk7231n_bootloader&type=code


Added after 1 [minutes]:

So I guess, for now, I need to take that into a conditional statement:

and call N SDK build twice from Github workflow yaml

Sounds great I might start looking into how to do this sorta thing myself as I find all this very interesting.

I'm no expert on this stuff as well so I really have no idea why the RF restore works, I just know it helped with the issue I was having, I don't understand what "configuring interface uap (with Static IP)WARN: TCPIP mutex is NOT locked (1) caller 53D07" means in terms of the RF mystery, it might not even be the problem.

Also thanks again for all your help, I am in no rush so happy to wait given we are in different time zones no pressure from me, there are plenty of times I will be unavailable as well

Ok so I made a 0x10000 file from backup from the first post:

I've added it here:
https://github.com/openshwprojects/OpenBK7231...mmit/5f19b009a83056a34c16e84e205547bbad3cddfa
I also modified scripts to allow extra argument to select build type:
https://github.com/openshwprojects/OpenBK7231...mmit/2fc6ba04b25c577abe91e5c9edb5adc76d1b6a35
https://github.com/openshwprojects/OpenBK7231...mmit/0dd12d65a28099184f3166727cda6238bd8c131c
However, I am now getting some Tuya packager error, so more is to come..


Added after 22 [minutes]:

69664-69530=134 ... 134 bytes too much in my bootloader, did I accidentally cut too much? Where would that lead me?

Those are just 0xFF bytes, I think I can strip them

Added after 8 [minutes]:

edit: no, still error:

I may just manually write that bootloader into generated qio...

Added after 57 [minutes]:

hm maybe I can just dd it::

terryb8s wrote:

Flashed 0x0 to 0x10000 from factory goodness backup

Flashed starting 0x10000 the OpenBK7231N_QIO_1.0.0.bin provided

0x10000 or 0x11000 ?

Works! using https://www.elektroda.com/rtvforum/topic4056533.html#21107630

First Test:
1. Erase all with BK7231 Easy UART
2. Flash OpenBK7231N_App_QIO_1.0.0.bin
3. Device boots! (Still has the TCPIP mutex is NOT locked (1) caller 53D07 error)
4. Connect via WiFi to device, connected fine, MAC ends in all 000000
5. Connected device to my WiFi network, access to device working!!! Awesome!

Second test
1. Erase all with BK7231 Easy UART
2. Flash factory dogness binary
3. Flash OpenBK7231N_App_QIO_1.0.0.bin
4. Device boots! (Still has the TCPIP mutex is NOT locked (1) caller 53D07 error)
5. Connect via WiFi to device from mobile device: failed, connect via second mobile device: connected, no access to Web App, connect via Windows PC: failed.
6. Flash only OBK config wireless network SSID and password, connected and working, MAC is c8:47:8c:00:00:00
7. Restore RF part, unique MAC present and connected to network SSID fine, I assume this likely has fixed the UAP issues as well but its late.

Sorry its taken me a bit since my last post, worklife busy over last couple of days.

Be keen to hear your thoughts on the WiFi issue and if there is anything I can do to help resolve that? I guess as long as people know that it might be an issue its fine?

Curious did you use 0x10000 or 0x11000 in the end?

Attached the boot if that's of any help just removed the SSID and password.

Awesome thank you! hoping I can learn some of the ways you achieved this for future devices Will be taking a look at the source in the git repo, hopefully I can learn a thing or two

Oh i see the WiFi error is gone in the boot.txt I attached, this was captured after a reboot...

I tried another reboot and it happened again though... weird.

I added encryption key reading to flasher, can you get latest build:
https://github.com/openshwprojects/BK7231GUIFlashTool/releases/tag/v1.2
And do just "Do firmware backup (read) only)" and show me what is there:

Can you check if it's working for you and what's it showing?

Added after 1 [minutes]:

I used 0x10000, see here:
https://github.com/openshwprojects/OpenBK7231...mmit/cf30fbec6d8ba48b2a70f5d8d23b5c980a304146