Bluetooth firmware not working

[Wenjie Wu]

The recent update of MicroBlocks seems to have broken the Bluetooth part ([env:esp32-ble]). This part has not been updated. I found that it cannot run today. It was no problem before.

here is the demo

[Wenjie Wu]

I found that running this line("BLEDevice::init") of code will fail, but there is no problem running it in Arduino.

‌

‌

‌

[John Maloney]

I have not changed that BLE code, but I did change the way MicroBlocks allocates memory. It is now allocating its dynamic object memory ("object store") from the heap (i.e. using malloc) instead of statically, and it is allocating much more memory than before. (That was don't to experiment with an ESP32 camera board.)

The new memory allocation may not be leaving enough memory for the BLE stack.

Try changing the amount of memory it allocates on line 53 of mem.c:

#elif defined(ARDUINO_ARCH_ESP32)
  #define OBJSTORE_BYTES 80000 // allocated from heap on ESP32

Try setting OBJSTORE_BYTES to 1000. If that allows BLE to work, then try increasing it. It would be great to find the threshold where BLE fails; we can back off from there.

If changing the memory allocation doesn't fix the problem, let me know and I'll try to think of what else it could be...

[Wenjie Wu]

You hit it !

I temporarily rolled it back to the previous version and it worked. I can already let microblocks send Bluetooth radio directly to OctoStudio without using a bridge

[Wenjie Wu]

  #if defined(BLE_PRIMS) || defined(OCTO_PRIMS)
    #define OBJSTORE_BYTES 8000
  #else
    #define OBJSTORE_BYTES 80000 // 48000 // max that compiles is 56000
  #endif

I'm using this configuration for now, if necessary I can commit

[John Maloney]

I can include this change in the next pilot release.

The OctoStudio connection is really cool! Great that you can now do it directly from ESP32 boards.

[John Maloney]

Just pushed the change to the dev branch.

[Wenjie Wu]

Just pushed the change to the dev branch.

👍

The OctoStudio connection is really cool! Great that you can now do it directly from ESP32 boards.

https://wwj718.github.io/post/img/microblocks-to-octo.mp4

I currently implement the part that sends message to OctoStudio directly in MicroBlocks (there are some annoying problems with letting the operating systems send BLE messages), and the part that receives messages from OctoStudio has not yet been migrated from the bridge(Python library). So currently the functions of sending and receiving OctoStudio BLE Radio are scattered in the bridge and MicroBlocks. I will try to implement both of them in MicroBlocks.

[John Maloney]

Can we close this issue once I pull your OctoStudio PR? (I'm still waiting to hear back from the OctoStudio team before pulling it. I doubt that they will object but want to give them a chance to raise an concerns.)

[Wenjie Wu]

I think it's considerate to give them a chance to raise any concerns before pulling it 👍.

I'm planning to spend more time on Bluetooth recently. I will continue to investigate the appropriate size for OBJSTORE_BYTES. Does the memory required for Bluetooth operation dynamically change? If so, how do we determine how much memory to reserve?

By the way, another thing I plan to do this weekend is to start building firmware for the esp32-s3. I've noticed that the esp32-s3 has generated a lot of enthusiasm among physical computing enthusiasts, more and more new boards are based on the esp32-s3., and this article has greatly piqued my interest:

‌

The CDC/JTAG mode of the ESP32-S3 refers to a specific USB operating mode that leverages the USB CDC (Communication Device Class) and JTAG (Joint Test Action Group) functionalities.

CDC (Communication Device Class): In this context, CDC mode allows the ESP32-S3 to emulate a serial communication device over USB. Essentially, it transforms the ESP32-S3 into a virtual COM port on a computer. This virtual COM port can be used for serial communication, similar to how you would connect an external device like an Arduino to a computer for programming or data exchange.
JTAG (Joint Test Action Group): JTAG is a standardized interface used for debugging and programming integrated circuits, including microcontrollers like the ESP32-S3. When the ESP32-S3 is in JTAG mode, it allows for direct communication with debugging tools and programming hardware via USB. This is especially useful during development and debugging phases, enabling tasks such as flashing firmware and performing advanced debugging operations.

With the built-in JTAG, we can step through debugging the vm! This is a huge help for me to understand and explore the vm.

[John Maloney]

I will continue to investigate the appropriate size for OBJSTORE_BYTES. Does the memory required for Bluetooth operation dynamically change? If so, how do we determine how much memory to reserve?

It's difficult to know exaclty when memory is allocated without detailed knowledge of how the BLE stack works, but we can do some experiments to find a good setting for OBJSTORE_BYTES. Create a test program the exercises BLE (e.g. a simple loop using the OctoStudio library). Run it on a VM with the current configuration, which doesn't crash. Then double OBJSTORE_BYTES and try again. Continue that process until it does crash. You can use binary search to find (with a few kbytes) the maximum OBJSTORE_BYTES that doesn't crash. Then, to be conservative, reduce that by some amount (say, 24k).

Note that WiFi may also require some dynamic memory. So you may want to include code to connect to a WiFi network in the test.

Re: ESP32-S3

Let me know how that goes. You may run into a few compile errors due to hardware differences. If so, you can temporarily comment out the offending code, then let me know. We can add an #ifdef to disable the code when the VM is compiled for an S3.

[Wenjie Wu]

‌

[env:m5stamps3]
platform = espressif32
board = m5stack-stamps3
board_build.partitions = noota_3g.csv
lib_deps =
    WebSockets
    256dpi/MQTT

[env:esp32-s3]
platform = espressif32
board = esp32-s3-devkitc-1
board_build.partitions = noota_3g.csv
lib_deps =
    WebSockets
    256dpi/MQTT

When I compiled the firmware for esp32-s3-devkitc-1, I encountered no problems. When I compile the firmware for m5stack-stamps3, I get the following error

vm/sensorPrims.cpp: In function 'void initSPI()':
vm/sensorPrims.cpp:278:14: error: 'MISO' was not declared in this scope
   setPinMode(MISO, INPUT);
              ^~~~
vm/sensorPrims.cpp:278:14: note: suggested alternative: 'EIO'
   setPinMode(MISO, INPUT);
              ^~~~
              EIO
vm/sensorPrims.cpp:279:14: error: 'MOSI' was not declared in this scope
   setPinMode(MOSI, OUTPUT);
              ^~~~
vm/sensorPrims.cpp:279:14: note: suggested alternative: 'M_PI'
   setPinMode(MOSI, OUTPUT);
              ^~~~
              M_PI
vm/sensorPrims.cpp:280:14: error: 'SCK' was not declared in this scope
   setPinMode(SCK, OUTPUT);
              ^~~
vm/sensorPrims.cpp:280:14: note: suggested alternative: 'SCL'
   setPinMode(SCK, OUTPUT);
              ^~~
              SCL

‌

[Wenjie Wu]

After commenting the above three lines, the following error will appear

/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:88:37: error: 'SCK' was not declared in this scope
         _sck = (_spi_num == FSPI) ? SCK : -1;
                                     ^~~
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:88:37: note: suggested alternative: 'SCL'
         _sck = (_spi_num == FSPI) ? SCK : -1;
                                     ^~~
                                     SCL
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:89:38: error: 'MISO' was not declared in this scope
         _miso = (_spi_num == FSPI) ? MISO : -1;
                                      ^~~~
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:89:38: note: suggested alternative: 'EIO'
         _miso = (_spi_num == FSPI) ? MISO : -1;
                                      ^~~~
                                      EIO
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:90:38: error: 'MOSI' was not declared in this scope
         _mosi = (_spi_num == FSPI) ? MOSI : -1;
                                      ^~~~
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:90:38: note: suggested alternative: 'M_PI'
         _mosi = (_spi_num == FSPI) ? MOSI : -1;
                                      ^~~~
                                      M_PI
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:91:36: error: 'SS' was not declared in this scope
         _ss = (_spi_num == FSPI) ? SS : -1;
                                    ^~
/Users/wwj718/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp:91:36: note: suggested alternative: 'PS'
         _ss = (_spi_num == FSPI) ? SS : -1;
                                    ^~
                                    PS

‌

[Wenjie Wu]

https://github.com/espressif/arduino-esp32/pull/8187 The solution is here

[John Maloney]

This is a bug in the Arduino library support for esp32-s3-devkitc-1, which was supposed to provide definitions for the default SPI pins. Glad there is already a PR that addresses the issue. Were you able to get platformio to compile using the PR? If so, what [env] entry did you use?

[Wenjie Wu]

These two [env] entries correspond to two boards. My board is esp32-s3-devkitc-1. It was compiled smoothly without any errors. m5stack-stamps3 is the board of another chinese user. I helped him write the [env] entry, and it has been compiled and passed. The previous problems are mainly related to his board. So far, everything has been compiled and passed. If there are more questions in the future, I will give feedback here.

[John Maloney]

I'm marking this as resolved since you got BLE working by reducing the object store memory. But feel free to add additional comments or email me about your experiments with the object store size.

[Wenjie Wu]

👌