How about release Apple silicon binary version ?

I am currently using BL616, but the compiled binary does not run properly after being flashed using BouffaloLabDevCube. I think it might be because the binaries generated by rust need to be flashed using other tools?

Does anyone have a copy of the Magichome Wifi LED controller's firmware based on BL602? I dumped mine using blflash but didn't notice that by default it is only dumping the 1st MB of memory and as far as I know that particular board has 2 MB...
Appreciate a copy of the original firmware. Already investigated if it is somewhere available for download officially by the manufacturer but didn't find anything. Thank you!

I have a Sonoff clone called Switch-WF on which I'd like to have custom code, after disassembly I've found BL602 inside.

After some fiddling I've found GPIO 8 and how to pull it high for flashing.

In general I follow https://lupyuen.github.io/articles/flash#flash-the-firmware

This is where I'm stuck, I'm getting timeout instead of entering eflash_loader.

Thanks for any ideas.

$ blflash flash sdk_app_helloworld.bin --port /dev/ttyACM0 
[INFO  blflash::flasher] Start connection...
[TRACE blflash::flasher] 5ms send count 55
[TRACE blflash::flasher] handshake sent elapsed 189.791µs
[INFO  blflash::flasher] Connection Succeed
[INFO  blflash] Bootrom version: 1
[TRACE blflash] Boot info: BootInfo { len: 14, bootrom_version: 1, otp_info: [0, 0, 0, 0, 3, 0, 0, 0, 85, a9, a8, 4c, b9, 7c, 19, 0] }
[INFO  blflash::flasher] Sending eflash_loader...
[INFO  blflash::flasher] Finished 2.546792544s 11.22KiB/s
[TRACE blflash::flasher] 5ms send count 500
[TRACE blflash::flasher] handshake sent elapsed 4.711691ms
Error: Timeout while running command

I've also tried lower speed using -b 115200, but no change.

Chip says: BL602L20

If I'm dumping using blflash-windows-amd64.exe dump LF686C.bin --initial-baud-rate 115200 --baud-rate 115200 --port COM10 for example, does blflash dump the whole memory? I see BL602 comes with optional onboard memory and it can be of varying size. I cannot determine from the IC package silkscreen how much memory is on the device I have. How can I be sure blflash dumps the whole thing?

this is on a new BL602. Does the eflash_loader need updating perhaps?

I am not sure where the problem is actually rooted but after some playing around, Wifi related stuff for my BL602 does not seem to work anymore. The SDK's demo bl602_demo_wifi flashes correctly but immediately gets into a reboot loop when booting the system. The sdk_app_http_client_socket firmware just prints on all WiFi related stuff "Wait Wi-Fi Mgr Startup..." in an endless loop.

I presume there is some junk somewhere in the flash memory left from previous attempts that now cause a problem. Is there a way to fully erase the flash with blflash so I can be sure everything is clean and tidy before reflashing a new firmware?

Bouffalo Lab will be shipping new versions of BL602 and BL604 with a different Embedded Flash...

https://gist.github.com/lupyuen/2cb2034a436dc75acc1aeb63ea3b9aa1

I think blflash will need to be updated. I shall study the changes to the new BLDevCube and figure out how to patch them into blflash. Will post my updates here thanks! 👍

When running the latest version from the release page, blflash 0.2.1, non-existing files are not detected but instead lead to Connection Succeed followed by an IO error while using serial port: Operation timed out after some time.

Full log:

$ ./blflash-linux-amd64 flash does-not-exist.bin --port /dev/ttyUSB0
[INFO  blflash::flasher] Start connection...
[TRACE blflash::flasher] 5ms send count 55
[TRACE blflash::flasher] handshake sent elapsed 581.196µs
[INFO  blflash::flasher] Connection Succeed
Error: IO error while using serial port: Operation timed out
caused by: Operation timed out
$ ./blflash-linux-amd64 --version
blflash 0.2.1

bitvec v0.22.3 has the dependency of funty v1.2.0 which has been yanked. There is currently no additional support for bitvec 0.22 versions. The author says to move to 1.0 or higher of bitvec.

It seems to make sense to also update the deku version as it also reference bitvec.

Current is deku v0.12 -> bitvec v0.22.3->funty v1.2.0
New is deku v0.15.0+->bitvec v1.0.1+->funty v2.0.0

i'm not sure on this, but i think the bootloader checks the uart for comm. if so:

the bootloader trigger could be automated by using a ft232rl module (very compact) in bitbang mode. just like how openOCD uses in one of it's mode.

ft232rl API:
https://ftdichip.com/Documents/AppNotes/AN_232R-01_Bit_Bang_Mode_Available_For_FT232R_and_Ft245R
http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf

i think the challenge will be to fiddle the single pin(tx) by inspecting the image...

i've seen a method where RPi is used: https://lupyuen.github.io/articles/auto
but this is more compact...

any thoughts?

Hi there get the following when trying to compile using cargo can ideas of work around

error: failed to compile blflash v0.3.3 (/home/arden/blflash/blflash), intermediate artifacts can be found at /home/arden/blflash/target

Caused by:
failed to select a version for the requirement funty = "~1.2"
candidate versions found which didn't match: 2.0.0, 1.1.0, 1.0.1, ...
location searched: crates.io index
required by package bitvec v0.22.3
... which is depended on by blflash v0.3.3 (/home/arden/blflash/blflash)