UNO R4 WiFi fails at BLE.begin()

Hello,

I would like to use the ArduinoBLE library with the UNO R4 WiFi. I have modified the Scan example to find my Bluetooth sensor using the BLE.scanForName() function, instead of BLE.scan(). This is successful. However, I am finding that I have to disconnect and then reconnect the UNO R4 WiFi prior to uploading the example. If I do not disconnect/reconnect the USB cable prior to upload, then the Scan example fails at BLE.begin().

Do I have to power off (disconnect/reconnect) the R4 Wifi every time I want to upload a sketch that uses the ArduinoBLE library? Is this a bug or expected behavior? Is there code that I should include prior to BLE.begin() to get the board in a state where it will not fail at BLE.begin()?

Thanks for any insight.

Yes it is both.

I made a small USB power switch board to help me with that.
See this post for how I made it:-
USB power switch

In my experience with the UNO R4 WiFi, BLE.begin() always fails to start if a connection was previously established and not closed with a peripheral.disconnect() before hitting the reset switch or trying to upload a new sketch.

If the device is only performing a scan then there are no issues with reset or or uploading a new sketch and BLE.begin() working as expected.

This is the first time I have worked with the BLE so it seems like a bug and very much unexpected behavior.
I would expect hitting the reset switch or uploading a new sketch would fully reset the device including the BLE module, but that doesn't appear to be the case.

For now I am using a USB hub with a power switch in order to avoid having to unplug and plug back in the cable every time.

Hi @ptillisch - is there anyway for the UNO R4 WiFi to reset the BLE module from within a sketch if the BLE.begin() instruction fails?

In my experience once a BLE connection has been established it is not possible to run a BLE sketch again without fully powering off the board (in my case unplugging it from USB since I am using the Serial Monitor).

Both hitting the reset switch or trying to upload a new sketch causes BLE.begin() to fail.

Thanks

There may be the sledgehammer approach to it, of trying to reset the whole ESP32 processor.

In another thread, talking about how to maybe reset the board properly to be able to upload a new program when the current program is setup for USB type of HID (like keyboard, mouse)...

Not sure if it will work in this case or not, or if it will also take out the sketch running on the RA4M1 processor as well...

I was planning to add the ESP32-S3 reset code to the touch 1200 code in SerialUSB.cpp. When the IDE changes the USB serial port baud to 1200, the touch 1200 reset code fakes a double tap reset so the RA4M1 enters its bootloader.

The next step is to add the ESP32-S3 reset before entering the RA4M1 bootloader. If needed, switch the USB mux back to the ESP32-S3 then reset the ESP32-S3 (AT+RESET\n) so the USB host enumerates the ESP32-S3. This SHOULD make the IDE auto upload work even if the sketch uses HID keyboard or mouse. No changes to the RA4M1 bootloader or the ESP32-S3 firmware should be needed. But I am away from my workshop for a while.

Thanks to @KurtE & @alranel I am using this code to reset the BLE module and then restart the sketch automatically whenever the BLE module fails to begin

  //Initialize BLE
  Serial.println("Starting BLE...");
  if (!BLE.begin()) {
    Serial.println("Reseting...");
    static const char RESET[] = "AT+RESET\n";
    Serial2.write(RESET, sizeof(RESET) - 1);
    delay(2000);
    NVIC_SystemReset();
  }

One thing (among many :wink: ) I am not sure about, is with the Serial2.write,
is who if anyone has started Serial2.

I know inside of WiFiS3 I believe it will call begin on its Modem object with the modem class default of 115200. In your case the call before this BLE.begin() will likely have already called it so it works.

But for other cases, like to reset from using HID or the like, you might need to add a call to Serial2.begin(115200);

Hi @KurtE - I do not have a call to Serial2.begin() in my sketch.
I assumed the BLE.begin() was establishing this somehow.

To make it work the only thing I had to do was add the delay before NVIC_SystemReset().
Without a delay BLE.begin() would still fail every time in a loop.

I am pretty sure that the BLE begin calls will call through the Wifi library to their begin method, so in your case it should be covered.

Hi @KurtE - I have found that when using the Serial Monitor at the time of the reset it doesn't reconnect.
I can hear the Windows chime when the device is lost.
Do you think there is a command to fix that?
It isn't a big deal to close the Serial Monitor window and open it again, which I am surprised actually works.

Sorry, your guess is as good (probably better) as mine. When playing with UNO WiFi these days, I am mostly using the one that USB Bypasses the ESP32...

Thanks for some suggestions on this issue. Most of it is beyond my scope of understanding. I am still looking for a solution where I can simply code the R4 Wifi using ArduinoBLE and display sensor data to the serial monitor without having to disconnect hardware or toggle the serial monitor on and off.

I did try the code suggested in post #7. This sort of worked, but it was unpredictable. Sometimes I had to relaunch the serial monitor, sometimes the Serial.println() in the code printed to the serial monitor, and sometimes it did not.

I attempted to move this code to the beginning of my program to run prior to calling BLE.begin(), with hopes of just resetting the R4 Wifi every time - and hoping that would allow BLE.begin() to be successful. This, unfortunately, has caused my R4 Wifi to no longer allow code to be uploaded. I tried to reinstall the firmware but now the Arduino IDE simply crashes (no matter what version of the firmware I try) when I run the Firmware Updater tool.

Were you able to get your R4 WiFi working again?

I assume double tapping the reset button is not working.
Have you tried manually jumpering the board into ESP32 mode?

uno-r4-wifi-usb-bridge/unor4wifi-updater at main · arduino/uno-r4-wifi-usb-bridge · GitHub

I have not been using the Serial Monitor because in my experience it seems to interfere with BLE activity, such as Discovering Attributes.
I think it might be a timing issue as the symptoms are not consistent.
I had one sketch where discovering attributes would always fail if a Serial.println command was present in the sketch.
When I commented out the Serial.println it would work most of the time after a large number of retries.
Just things like that, and the fact BLE.begin fails so often, it feels like BLE needs a lot of attention on the UNO R4 WiFi.