Shenzhen Pinmei / Linklemo A9 Mini Camera with Beken BK7252NQN481 – Photos, Boot Log, Flash Backup

insmod wrote:

BK7252N build, untested.

congratulations. 1680_merge_55ebe0a12aba QIO flashed:





only BL log from TX pad on this device. OTA is successful to and from 1680_merge_55ebe0a12aba and _7231u_t_b0f287a571d0




Added after 3 [minutes]:

P2 is blue LED on this A9 and it is controllable

That's the great news! I assume it's the new PR that was open?

p.kaczmarek2 wrote:

That's the great news! I assume it's the new PR that was open?

yes. I think I need to try turning a couple of these BK7252U/N cams into dev boards or something. I fear some of the test pads are getting a bit ropey with all the soldering and moving about.

Added after 46 [seconds]:

or find some BK7252U/N modules I suppose

It seems acceptable on my side.
https://github.com/openshwprojects/OpenBK7231T_App/pull/1680
@insmod is it ready to merge? No breaking change?

DeepSleep still works?

>>21587270
DeepSleep changes are only for new SDK and mostly cosmetic, functionality is untouched.

I recently noticed a mention that realloc is broken not only on T, but on N too (while os_realloc works fine).
Does this mean that it can become a problem in tcp server? And perhaps change realloc to os_realloc in cJSON for T and N and enable it on T?

I may be wrong, but I seem to remember that it was remapped to os_realloc:

OpenBK7231T\apps\OpenBK7231T_App\src\hal\bk7231\hal_main_bk7231.c

Currently I don't even know why they are different on SDK side. So probably just extend this fix for N...

Added after 1 [minutes]:

Related: https://github.com/openshwprojects/OpenBK7231T_App/issues/298

Added after 57 [seconds]:

It seems it was back in 2022 when I debugged it so it's possible that some things have changed..

Does it even work?
In new SDK realloc is wrapped (to os_realloc).

I was sure that it works. I've retested now and I am not sure.

It seems that realloc on N is still RARELY (but still) mangling the bytes?



Huh. I rerun it and I can't reproduce that.

Question just partially related to new PRs - @insmod , any ideas why some builds fail randomly with something like memory corruption error in PRs?
https://github.com/openshwprojects/OpenBK7231T_App/pull/1694

I don't know, crash is either in rt_ota_packaging_tool_cli or package.
New sdk has rt_ota_packaging_tool_cli-x64 and rt_ota_packaging_tool_cli-x86, you can try to use them.

Thanks for your great work! I'm on a cheap chinese cam very similar to the one of the topic and running on the same MCU. It has INO-A10N-V2.3 Ca13 printed on PCB. I was triyng to get it streaming without Linklemo app. I managed to get boot log. Now I'm trying to read firmware with no luck. I'm on linux, I don't have Windows (though I'm thinking to install a virtual one). I connected V3.3, GND, Rx and Tx pins to my USB to UART adapter that can read correctly any log but I'm missing something because bk_loader is unable to read flash. I think I have to do something to put MCU in bootloader/download mode. @divadiow!!! How did you do it?
Thanks again

my experiences to date have been in Windows using Easy Flasher and BKFIL. There is a Linux BKFIL

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

https://github.com/openshwprojects/FlashTools/tree/main/Beken/Linux

I'm using linux command line BKFIL application (bk_loader) but after "Getting Bus..." I get "LinkCheck Timeout". I supposed that MCU isn't in correct mode. I was asking if you did some kind of operation to put it in "read (or write) mode"... I read something about CEN to GND but I didn't find anything about in you posts. Can you help me please?

Oh yes. Forgot bk_loader is behind BKFIL.

Simply applying power, like with BK7231, should be enough to start the flash backup at the right moment. Are your wires short?

Are you powering cam from USB UART adaptor solely? This may not be able to give it enough power.

Added after 5 [minutes]:

Battery was de-soldered and power applied from micro-USB port. Common grounds.

Yes, I'm powering from adapter, 3.3V and GND. Blue led blinks 4 times... power seems to be enough, wires are less than 10cm long. Cam never had battery but has BAT+ and GND pads, the ones I'm powering.

Hmm. I still wouldn't trust power from USB-TTL alone.

I'm thinking of some compatibility problems of application with this chip because during read attempt I see both rx and tx leds on adapter blinking so it should mean that MPU is responding...I noticed that app version for linux is stuck on V2.1.11.15 though windows one is at V3.0.1.4. I didn't find sources for that application to build it myself. I''l try to put up a virtual machine with windows and see if things will go better. Thank you.

Found a pic I didn't post. Shows me powering from micro-USB. This was SPI flash rig though



Added after 16 [minutes]:

Laloshifrin wrote:

I noticed that app version for linux is stuck on V2.1.11.15 though windows one is at V3.0.1.4.

There's also a 2.x line for Windows and it seems to have more recent releases than 3.x

https://dl.bekencorp.com/tools/flash

I'm not sure of the difference or purpose.

Nothing new with Windows. I'll try to find a 3.3V supply to check if it's a power problem.

Ok. Does the cam not have a usb port?

yes it has. It's the only official way to power cam. On the board there are battery pads but no battery was never installed.

Added after 1 [minutes]:

divadiow wrote:

Battery was de-soldered and power applied from micro-USB port.

So you powered it with 5V?

Laloshifrin wrote:

So you powered it with 5V?

Yes, I powered it with 5V USB. There’ll be an LDO on the PCB to step it down to 3.3V for the Beken MCU and other components. Just make sure you have a common ground between the USB-TTL adapter and the board.

Added after 11 [minutes]:

If a device takes USB 5V or 12/24v barrel jack connector I tend to use that for power rather than bothering to solder up 3.3v

eg

I didn't try with normal USB power. I will...

Having a look at log I assume that if I trigger reading at this stage it should work:
---------------------------------------------------------------------------------------------------------------------------------------------------------------
go os_addr(0x10000)..........
[D/FAL] (fal_flash_init:63) Flash device | beken_onchip | addr: 0x00000000 | len: 0x00400000 | blk_size: 0x00001000 |initialized finish.
[D/FAL] (fal_flash_init:63) Flash device | beken_onchip_crc | addr: 0x00000000 | len: 0x00400000 | blk_size: 0x00001000 |initialized finish.
[D/FAL] (fal_partition_init:176) Find the partition table on 'beken_onchip_crc' offset @0x0000d364.
[I/FAL] ==================== FAL partition table ====================
[I/FAL] | name | flash_dev | offset | length |
[I/FAL] -------------------------------------------------------------
[I/FAL] | download | beken_onchip | 0x00132000 | 0x000ae000 |
[I/FAL] | app | beken_onchip_crc | 0x00010000 | 0x00110000 |
[I/FAL] | bootloader | beken_onchip_crc | 0x00000000 | 0x00010000 |
[I/FAL] =============================================================
[I/FAL] RT-Thread Flash Abstraction Layer (V0.4.0) initialize success.
ROMFS File System initialized!
msh />W (908) sd_card: CMD8 SEND_IF_COND err:-3902
W (912) sd_card: CMD55 APP_CMD err:-3902
SD File System initialzation failed!
Enter normal mode...
---------------------------------------------------------------------------------------------------------------------------------------------------------

...or not?

Added after 1 [minutes]:

divadiow wrote:

If a device takes USB 5V or 12/24v barrel jack connector I tend to use that for power rather than bothering to solder up 3.3v

I thought that 3.3V were necessary to get flash mode.

Laloshifrin wrote:

Having a look at log I assume that if I trigger reading at this stage it should work:

Negative. It'll catch it before any log output, within a split second after power on or CEN.

Laloshifrin wrote:

I thought that 3.3V were necessary to get flash mode

Whatever the input is, the MCU will still be 3.3v powered. For non-mains powered devices that accept 5v/12v etc, this presents a slightly more convenient and sure way to power device.

Added after 9 [minutes]:

To be clear this is powering the device how it would be in normal operation. Eg via USB port, if present. Not soldering up to BAT+ contacts or direct to any 3.3v test pads and sending 5v that way.

What happened is really astonishing to me and my little experience, maybe you got an explanation:
connecting power didn't work at all but i noticed that without it rx led on interface was continuously blinking. I ran read and it worked like a charm!!!
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
bk_loader version 2.1.11.8: build @_MaY_ 8 2024 23:15:55
2025-08-06 00:57:49.689 start Read thread.
2025-08-06 00:57:50.347 Current port : /dev/ttyUSB0 + BaudRate : 115200 connect success
2025-08-06 00:57:50.347 do_reset_signal
2025-08-06 00:57:50.347 Getting Bus...
2025-08-06 00:57:50.630 Gotten Bus...
2025-08-06 00:57:50.636 Current Chip is : BK7252N
2025-08-06 00:57:50.663 Current baudrate : 115200 success
2025-08-06 00:57:50.664 [ 0 ] file_startAddr : 0x00000000
2025-08-06 00:57:50.664 [ 0 ] file_path : /beken/BEKEN_BKFIL_V2.1.11.8_20240509/a-1.bin
2025-08-06 00:57:50.664 [ 0 ] file_length : 0x400000 (4096 KB)
2025-08-06 00:57:50.664 [ 0 ] file_crc : 0x0
2025-08-06 00:57:50.664 Begin ReadFlash...
2025-08-06 01:03:56.936 [ 0 ] Successfully, file path : /beken/BEKEN_BKFIL_V2.1.11.8_20240509/a-1.bin_dump_20250806_005750_0x0_0x400000.bin
2025-08-06 01:03:56.942 End ReadFlash!
2025-08-06 01:03:56.973 Boot_Reboot

2025-08-06 01:03:57.765 Total Test Time : 367.135 s
2025-08-06 01:03:57.765 Read Flash OK

2025-08-06 01:03:57.766
==============================================================
_ (done)
| |
__| | ___ _ __ ___
/ _ |/ _ \| _ \ / _ \
| (_| | (_) | | | | __/
\__,_|\___/|_| |_|\___|
{All Finished Successfully}
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
had a quick look at the dump and there should be the bootloader in the beginning and the rest of flash after 0x10000. I'll try to go deeper but I think that at least I dumped it correctly, I saw lots of cleartext data so I assume no encryption and correct reading.
How it could work without power remains a mistery to me!!!!

cool. I have seen and experienced this before. When this has happened my assumption was that the current in RX/TX alone was enough to power the MCU, which tends to the be opposite of the case, hence the push to use a decent power source. I'm not sure if that is correct, so I'd welcome the comment of others on this scenario.

Added after 3 [hours] 26 [minutes]:

What are your next steps? Will you continue to use Linklemo or look to develop your own firmware/maybe add cam support to OpenBeken if you are able to code stuff? Maybe try to get something similar to cam-reverse working with factory firmware?

Unfortunately developing a firmware is far beyond my skills.
At the moment I'm exploring. I noticed that even though from log it looks like flash is 4MB the data read is 2MB repeated twice. Now I'll try to read data splitting blocks:
[D/1970-01-01 00:00:00.932] [dev.flash /00504] : 0 | Bootloader | owner:0 | 0x00000000 | 0x0000F000
[D/1970-01-01 00:00:00.941] [dev.flash /00504] : 1 | Application | owner:0 | 0x00011000 | 0x001C2000
[D/1970-01-01 00:00:00.951] [dev.flash /00504] : 2 | (null) | owner:0 | 0x00000000 | 0x00000000
[D/1970-01-01 00:00:00.960] [dev.flash /00504] : 3 | RF Firmware | owner:0 | 0x001E0000 | 0x00001000
[D/1970-01-01 00:00:00.970] [dev.flash /00504] : 4 | NET info | owner:0 | 0x001E1000 | 0x00001000
[D/1970-01-01 00:00:00.980] [dev.flash /00504] : 5 | xc config1 | owner:0 | 0x001F4000 | 0x00001000
[D/1970-01-01 00:00:00.989] [dev.flash /00504] : 6 | xc config | owner:0 | 0x001F5000 | 0x00005000
[D/1970-01-01 00:00:00.999] [dev.flash /00504] : 7 | (null) | owner:0 | 0x00000000 | 0x00000000
[D/1970-01-01 00:00:01.008] [dev.flash /00504] : 8 | ble bonding info | owner:0 | 0x001F0000 | 0x00001000
addresses seem to be correct.
I noticed that there are cleartext wifi passwords so I want to look for telnet password somewhere, maybe I can reach my goal with telnet commands.
Even if I'm scared to brick the cam I'd like to try to change wifi password to check if bk_loader works also in writing... I hope there's no CRC check...
Do you know how to use bk_loader tool?
Usage: ./bk_loader tool [OPTIONS] [SUBCOMMAND]

Options:
-h,--help Print this help message and exit

Subcommands:
json_2_bin parse json file ,and create a bin file
bin_2_json parse bin file ,and create a json file

there's no docs and I only get errors.
Any advice will be extremely appreciated. I'll let you know what happens. Thanks for the support.

PS - There are 3.3V between RX and GND and between TX and GND on the USB adapter! Maybe this is the explanation.

This is the explanation:

Great clarification though it doesn't actually explain why if I connect Vbat 3.3V connector MCU boots normally and flash won't be read. Thank you.

Added after 34 [minutes]:

Tried to write 1 byte to change wifi AP password but something went wrong and now cam is stuck in some kind of boot loop :(

Added after 17 [minutes]:

bk_loader wrote correctly the byte I wanted but erased to FF next 254 bytes!🤬
hope I can recover :(

Added after 3 [hours] 2 [minutes]:

Fixed! 🥵
...though if I try to change 1 character of wifi password cam won't boot correctly! Could there be some CRC?