sparkfun / Arduino_Apollo3

Arduino core to support the Apollo3 microcontroller from Ambiq Micro
83 stars 39 forks source link

BLE functionality broken since updating to ArduinoBLE v1.2.0 #362

Closed idea--list closed 3 years ago

idea--list commented 3 years ago

Hi there,

Some days ago i reported over here that BLE is working both in Mbed OS and in Arduino.

Since that time ArduinoBLLE v1.2.0 has been released. That combined with Artemis core v2.0.5 causes hard fault while trying to run any BLE examples.

paulvha commented 3 years ago

Well this is very weird one and it took me a lot of time to figure out.. Root cause The root cause is related to declaring many functions "virtual" for the following driver parts of the ArduinoBLE:

grep -r -nHIirF -- FAKE (in directory: /home/paul/Arduino/libraries/ArduinoBLE/src)
./local/BLELocalDevice.cpp:356:#if !defined(FAKE_BLELOCALDEVICE)
./utility/GATT.cpp:175:#if !defined(FAKE_GATT)
./utility/GAP.cpp:261:#if !defined(FAKE_GAP)
./utility/L2CAPSignaling.cpp:171:#if !defined(FAKE_L2CAP)
./utility/HCI.cpp:689:#if !defined(FAKE_HCI)
./utility/ATT.cpp:1691:#if !defined(FAKE_ATT)
Search completed with 6 matches.

The result is memory crashes on unexpected moments.

I am not familiar with the virtual approach, but reading: virtual functions gave me some idea With declaring many functions virtual you also get a different way to address these functions. E.g. each of the above classes is now defined as a pointer like :

#if !defined(FAKE_BLELOCALDEVICE)
BLELocalDevice BLEObj;
BLELocalDevice& BLE = BLEObj;
#endif

instead of BLELocalDevice BLE; In the corresponding .h files this check on defined FAKE_ is not happening. It just assumes a pointer extern BLELocalDevice& BLE;

Test done I took the LED-peripheral that is part of ArduinoBLE. Using the new ArduinoBLE 1.20, but changed back the pointer approach in (Only on this place !!) BLELocalDevice.cpp to: BLELocalDevice BLE; BLELocalDevice.h back to: extern BLELocalDevice BLE;

Now a normal BLE.begin() is working and sets the ATP board up for BLE correctly. The BLE.setLocalName("LED") is working, BUT BLE.setAdvertisedService(ledService); is still causing a crash (blue blinking LED). Then BleLocalDevice.h I removed "virtual" before the calls: (the one call calls the other the other).

   bool setAdvertisedServiceUuid(const char* advertisedServiceUuid);
   bool setAdvertisedService(const BLEService& service);

Now BLE.setAdvertisedService(ledService) is working as well. From then on the LED-peripheral works.

I have tried to compile the ArduinoBLE 1.20 as downloaded for Arduino Nano 33 BLE... works without problems unchanged.

Solution

The GCC-ARM compiler used by Sparkfun is from Q4-2018. I have changed that to the latest Q4-2020 .I also had to recompile the Mbed to a new libmbed-os.a to make it work. BUT then it works. No changes needed to ArduinoBLE. I have tested on Linux/Ubuntu. The other nice aspect is that the libmbed-os.a with Q4-2020 release is 48MB, compared to 60MB with earlier compiler version.

HOWEVER..... !!! ONE aspect. In mbed-os/features/FEATURE_BLE/targets/TARGET_Ambiq_Micro/hal/apollo3/hci_drv_apollo3.c there is ALSO a definition of global "BLE" and as such the linker is failing as ArduinoBLE uses that. That was already the case before, It is only now detected with the new compiler. In the file hci_drv_apollo3.c I have changed BLE to BLEM (module). Then created a new libmbed-os.a and then it ALL worked. I have attached the updated file.

  1. Update the compiler (.....sparkfun/tools/arm-none-eabi-gcc)
  2. Update hci_drv_apollo3.c
  3. recompile the libraries (libmbed-os.a)

regards, Paul

hci_drv_apollo3.zip

Wenn0101 commented 3 years ago

@paulvha Thank you so much for you contributions! It takes some serious effort to chase down these issues and I appreciate your dedication!

I have taken your suggestions and plan on including them in the next release v2.0.6, see https://github.com/sparkfun/Arduino_Apollo3/discussions/368 to preview release.

jerabaul29 commented 3 years ago

Will the compiler update also be effective on the core v1 @Wenn0101 ? If this is little enough work would be great for those of us still using core v1 for a reason or another :) .