WiFi flash and ram memory consumption way too high

[harbaum]

WiFi eats a lot of flash and nearly all of the RAM. The resulting flash is unreliable and flashing hangs at flash erase. But more importantly there's not enough ram left for a useful application.

Memory region         Used Size  Region Size  %age Used
fw_header_memory:         256 B         4 KB      6.25%
      xip_memory:      876264 B         4 MB     20.89%
       ram_psram:          0 GB         4 MB      0.00%
     ram_nocache:       18500 B       319 KB      5.66%
      ram_memory:       75752 B       319 KB     23.19%
        ram_wifi:      144016 B       160 KB     87.90%

Also most of the WiFi seems to be closed source and the debug output is a new line/return mess. And finally WiFi and USB host don't seem to go nicely and the system often hangs during boot when enabling both.

Can WiFi be simplified with a few simple examples not depending on a shell and the like which wouldn't be used in real-life-scenarios?

[WGR7]

It's a dead repo with a dead product. If at least, BouffaloLab could give a good documentation.

[harbaum]

A few days ago I have actually started to migrate my retro FPGA support MCU for the MiSTeryNano to the Pi Pico. I'll continue to support the BL616 but there will be the option to use the rp2040 and probably also the esp32-s2/3. All of these have inferior USB host capabilities and I really like the bl616 ... but the SDK definitely is a problem. Too bad ...

[WGR7]

Yes, for sure. Seems that BLab has abandoned BL616/618 because they are missing on products BLab page. I'm waiting for esp32-p4 that will have great peripherals, I hope that price can be affordable.

[gamelaster]

@WGR7 BL618/BL616 is still maintained by Bouffalo, together with BL70X/BL70XL.

[WGR7]

@gamelaster maybe it's true, but doesn't matter because there's no updates on SDK and support is dead.

[gamelaster]

@WGR7 about updates on SDK, yes, those are bit slow recently, but it should be updated in some near time. About support, yeah, that's unfortunate.

[harbaum]

The problem is not the low update frequency. The problem is the SDK itself. E.g. major parts of WiFi and Bluetooth are inside closed source libraries:

bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl808_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m10s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1sbredr1.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btprofile/lib/libbtprofile.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6_matter.a

These contain not only the basic RF functions but major parts of the protocol stacks and even parts of demo applications. According the the bl616 datasheet, it e.g. supports classic bluetooth. I was delighted and expected to be able to add bluetooth HID support to my retro FPGA project to use wireless bluetooth controllers with it. In reality there is one demo that implements audio parts for classic bluetooth. But that needs one specific version of the libraries which in turn lacks other aspects i needed. And since this is all closed source you cannot debug it or even dig through the source code to understand how to use it.

The device seems great and the highspeed USB host is a great thing. But it's nearly impossible to implement complex projects that are not directly covered by the examples.

[gamelaster]

@harbaum this is sadly true, BT/BLE and WiFi is indeed too much packed into blobs for some reason, unnecessary. Also, BL618 doesn't explain all the information about clock and power trees. Previous generation of chips (BL60X and BL70X) were better in this. To other side, BL61X and BL808 were kinda rushed...

[O2C14]

The problem is not the low update frequency. The problem is the SDK itself. E.g. major parts of WiFi and Bluetooth are inside closed source libraries:

bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl808_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m10s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1sbredr1.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btprofile/lib/libbtprofile.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6_matter.a

These contain not only the basic RF functions but major parts of the protocol stacks and even parts of demo applications. According the the bl616 datasheet, it e.g. supports classic bluetooth. I was delighted and expected to be able to add bluetooth HID support to my retro FPGA project to use wireless bluetooth controllers with it. In reality there is one demo that implements audio parts for classic bluetooth. But that needs one specific version of the libraries which in turn lacks other aspects i needed. And since this is all closed source you cannot debug it or even dig through the source code to understand how to use it.

The device seems great and the highspeed USB host is a great thing. But it's nearly impossible to implement complex projects that are not directly covered by the examples.

In fact, partial source code from Sophgo can be used (for example: https://github.com/sophgo/cvi_alios_open/blob/master/components/ble_host/bt_host/host/a2dp.c ）To replace libbtprofile.a, HID may be implemented. And through this method, I have already implemented LDAC decoding on AI think m61

[harbaum]

To me it seems more like these chips were made for a specific customer with a specific use case (in this case maybe some bluetooth audio application). This has then been implemented by combining all kinds of existing open source solutions. And it looks like this happened in a rush and rather than cleanly integrating different projects they were tightly mixed and modified until the use case was covered. The resulting SDK now consists of lots of components that rely on each other for no apparent reason. This also explains those different closed source bluetooth libs. They also cover specific use cases and are not really generic.

[harbaum]

In fact, partial source code from Sophgo can be used (for example: https://github.com/sophgo/cvi_alios_open/blob/master/components/ble_host/bt_host/host/a2dp.c ）To replace libbtprofile.a, HID may be implemented. And through this method, I have already implemented LDAC decoding on AI think m61

I was able to implement BT-LE HID support. Unfortunately only very few pure BT-LE HID devices exist and the majority is still classic BT. This includes e.g. the 8bit do ones and the Nintendo Joycons and I wasn't able to even isolate the classic BT stuff I'll n the SDK to compile a raw basic application that would allow me to e.g. scan for devices. So I gave up. A few weeks later I started using WiFi and ran into very similar issues. Trying to connect to an AP gave nul pointer assertions in the closed source part which were eventually resolved by randomly poking in the proj.conf. Once it was able to connect it ran out of memory and/or e.g. the USB started to become unreliable. When trying to initiate an AP scan the FreeRTOS tasks stopped working once the scan completed ... I don't even know if wifi and FreeRTOS are supposed to work together.

So while it may be possible to hack around some of these issues I expect to run in similar issues over and over again. That's not useful for an open source project like mine where others are supposed to continue on my work. I already started to distribute patched versions of the SDK and the CherryUSB stack with my project.

I am now porting everything over to the Pico and ESP32 and then people have the choice. I'll keep supporting the BL616 and whenever it looks like classic BT becomes usable or Wifi is stable enough to be integrated this can still be added. For now I use the BL616 as a USB host only and if you want Bluetooth or WiFi you need to use one of the other controllers.

[O2C14]

I am trying to port BTstack to BL618, and it can now be detected by classic Bluetooth devices, but it cannot be connected. I think this is just a scheduling issue with BTstack.

[harbaum]

Cool. I was once considering giving tinyUSB a try as it had support for ehci controllers.

But for Bluetooth you still need the closed source RF Part inside one of those libraries, don't you? If scanning and active connecting work I might be tempted to give it a try. I already have the whole hid layer working for USB, so adding Bluetooth hid should not be too complex if l2cap is running.

Also WiFi won't work with that, would it?

[O2C14]

I'm not really interested in WIFI, so I haven't worked on the bl618's WIFI module. I'm doing all this work to realize a complete A2DP application

[harbaum]

But you are still using the closed source library for the low level stuff, don't you?

[O2C14]

It doesn't matter, only the Bluetooth controller is closed source. I just need to wrap the closed-source API into a usable interface for btstack.

[O2C14]

Porting btstack was successful!, Now it can be connected and other btstack features are being verified.

[gamelaster]

@O2C14 amazing! Will you share your work later?

[O2C14]

Of course, I am currently organizing the code. Unfortunately, I am preparing for the final exam and may analyze this later

[gamelaster]

No worries. Good luck with final exams!

[O2C14]

All the code is here:https://github.com/O2C14/btstack_test Only tested under btstack v1.6.1

[O2C14]

I implemented the ldac player with btstack

[harbaum]

That's really impressive. I definitely need to have a closer look at that.

[amitv87]

MiSTeryNano

You can try the ai-thinker sdk. Only the software MAC layer is available as a static library, rest everything related to wi-fi is open (event the wpa supplicant).