SuperB ESP32: BLE + Wifi ==> crash due to partitions

General Discussion
#1

Hello,

I’ve been using the wifi capability of the SuperB for a while now, and it’s great. I’ve recently decided to add BLE functionality, and now things are not so good. Including the BLE library grows the firmware size beyond the 1.4MB of the default app_0 partition, so it won’t upload. No problem, I’ll just add a partition to the superb section in the boards.txt, and I’ll be good to go. I tried both ‘min_spiffs’ and ‘huge_app’, and neither worked: instant crash on startup with either (doesn’t even get to my code). I’m guessing the partitions didn’t get created according to my settings, which were:

superb.menu.PartitionScheme.default=Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS)
superb.menu.PartitionScheme.default.build.partitions=default
superb.menu.PartitionScheme.huge_app=Huge APP (3MB No OTA/1MB SPIFFS)
superb.menu.PartitionScheme.huge_app.build.partitions=huge_app
superb.menu.PartitionScheme.huge_app.upload.maximum_size=3145728
superb.menu.PartitionScheme.min_spiffs=Minimal SPIFFS (1.9MB APP with OTA/190KB SPIFFS)
superb.menu.PartitionScheme.min_spiffs.build.partitions=min_spiffs
superb.menu.PartitionScheme.min_spiffs.upload.maximum_size=1966080

Anyone else have this happen? It should work, but doesn’t, so I’m wondering if there’s something specific about the SuperB implementation of the ESP32 that “hardcodes” the partitions somehow. Anyone successfully run a SuperB with both BLE and Wifi libs?

By the way, the flashing works fine:

Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: b4:e6:2d:dd:3e:09
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 16MB
Compressed 8192 bytes to 47...

Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4681.2 kbit/s)...
Hash of data verified.
Flash params set to 0x0240
Compressed 15872 bytes to 10319...

Writing at 0x00001000... (100 %)
Wrote 15872 bytes (10319 compressed) at 0x00001000 in 0.9 seconds (effective 140.2 kbit/s)...
Hash of data verified.
Compressed 1515696 bytes to 888494...

Writing at 0x00010000... (1 %)
...
Writing at 0x000e8000... (100 %)
Wrote 1515696 bytes (888494 compressed) at 0x00010000 in 77.7 seconds (effective 156.1 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 118...

Writing at 0x00008000... (100 %)
Wrote 3072 bytes (118 compressed) at 0x00008000 in 0.0 seconds (effective 1170.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Thanks!

#2

I basically fall into a reboot loop that shows this:

ets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac

None of which means anything to me… :wink:

#3

Well, this isn’t super helpful to you but I have successfully compiled sketches for the A0 that use WiFi and Bluetooth at the same time. You are correct, you cannot do this with the default partition layout, it’s just too large. I use minimal spiffs (1.9mb application, OTA, 190Kb SPIFFS). This works fine on an A0 which is, of course, also an ESP32.

The SuperB uses an ESP32-WROOM-32D module. This module has 4MB of FLASH. Your text shows it autodetecting 16MB! That’s not correct. I don’t know if that messes anything up but it might. Between that and maybe your partitions being weird you could easily not be able to boot.

Your reset reason is software related would would suggest that some form of software is loaded and asking for the reset - likely the start up code is detecting something dumb and forcing a reboot. But, in that case you should have more output after the entry … line. Do you get a more detailed crash reason in between?

I have to admit, I never did much with the SupeB, instead moving straight to the A0. But, hopefully we can still get this figured out.

#4

Thanks Colin, and actually it was helpful! It confirmed that it should work, so I dug deeper. Much deeper. I now know way more about the Arduino build system than I ever wanted to. The good news is: I got it working! So yay. :grinning:

Now, the problems with the Macchina instructions are:

  1. The platform.txt needs to be changed to actually use the flash_size setting from the settings instead of detect (line 100 and 101), because the flash size is incorrectly detected. Changing to --flash_size 4MB fixes this. Using --flash_size {build.flash_size} would more portable though (in the cases where people use other ESP32 boards too… but, see (2).

  2. The flash size is incorrectly set in board.txt file we are instructed to use. The superb.build.flash_size=4MB is set correctly, but later on there’s a menu option that reads superb.menu.FlashSize.2M.build.flash_size=2MB, which will override the setting we want. Not sure why these are different, but it’s definitely a problem. Are we even sure the board doesn’t just have 2MB (i.e. 16Mbits)?

  3. There is a similar mix up in the partition selection. There are 3 partition settings in the boards.txt file:
    3.1) superb.build.partitions=default
    3.2) superb.menu.PartitionScheme.default.build.partitions=default
    3.3) superb.menu.FlashSize.2M.build.partitions=minimal
    The outcome of this mishmash of settings is that the partition that gets compiled by gen_esp32part is minimal and the not the one shown in the menu. Why there’s a setting for partition in the flash size menu option, I don’t know, doesn’t make sense to me.

I’m honestly not sure why we have menu items in the board.txt for most of these things because they each have a single item in the list. Why not just remove them? The only one that could be useful is the partition selector, and it doesn’t even work. I also ended up adding the remaining options for debug level, as that is super useful to have too.

So, in short, here is the boards.txt I would recommend that corrects these mistakes and enables BLE + WIFI to work out of the box:

superb.name=SuperB on M2

superb.upload.tool=esptool_py
superb.upload.speed=115200
superb.upload.maximum_data_size=327680
superb.upload.wait_for_upload_port=true

superb.serial.disableDTR=true
superb.serial.disableRTS=true

superb.build.mcu=esp32
superb.build.core=esp32
superb.build.variant=esp32
superb.build.board=esp32_DEV

superb.build.f_cpu=240000000L
superb.build.flash_size=4MB
superb.build.flash_freq=40m
superb.build.flash_mode=dio
superb.build.boot=dio
superb.build.partitions=min_spiffs
superb.build.defines=

superb.menu.PartitionScheme.min_spiffs=Default OTA App (Max 1.9MB APP) with 190KB SPIFFS
superb.menu.PartitionScheme.min_spiffs.build.partitions=min_spiffs
superb.menu.PartitionScheme.min_spiffs.upload.maximum_size=1966080
superb.menu.PartitionScheme.huge_app=Large App (Max 3MB) without OTA and a 1MB SPIFFS)
superb.menu.PartitionScheme.huge_app.build.partitions=huge_app
superb.menu.PartitionScheme.huge_app.upload.maximum_size=3145728

superb.menu.DebugLevel.none=None
superb.menu.DebugLevel.none.build.code_debug=0
superb.menu.DebugLevel.error=Error
superb.menu.DebugLevel.error.build.code_debug=1
superb.menu.DebugLevel.warn=Warn
superb.menu.DebugLevel.warn.build.code_debug=2
superb.menu.DebugLevel.info=Info
superb.menu.DebugLevel.info.build.code_debug=3
superb.menu.DebugLevel.debug=Debug
superb.menu.DebugLevel.debug.build.code_debug=4
superb.menu.DebugLevel.verbose=Verbose
superb.menu.DebugLevel.verbose.build.code_debug=5

With these changes, the board config looks much cleaner in my opinion.

image
image693×204 5.02 KB

#5

Damn, the module runs really hot with both BLE and WIFI running at the same time. Should I be worried about it melting? Should I introduce delay statements in my loop() to get it to take a breather?