Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BLE.begin() hangs whenever I import STM32FreeRTOS library #63

Closed
jayadamsmorgan opened this issue Nov 13, 2023 · 2 comments
Closed

BLE.begin() hangs whenever I import STM32FreeRTOS library #63

jayadamsmorgan opened this issue Nov 13, 2023 · 2 comments
Labels
question Further information is requested

Comments

@jayadamsmorgan
Copy link

jayadamsmorgan commented Nov 13, 2023

Describe the bug
Whenever I import STM32FreeRTOS the program hangs on BLE.begin() and nothing happens. My board is P-Nucleo-WB55. I did update STM32WB Copro Wireless Binaries to the latest ones. As soon as I comment out #include STM32FreeRTOS everything works perfectly. I tried several examples, they all work perfectly unless I include STM32FreeRTOS library. STM32FreeRTOS library itself works fine if I don't use BLE.begin().

To Reproduce

#include "Arduino.h"
#include "STM32FreeRTOS.h"
#include "STM32duinoBLE.h"

HCISharedMemTransportClass HCISharedMemTransport;
BLELocalDevice BLEObj(&HCISharedMemTransport);
BLELocalDevice& BLE = BLEObj;

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  BLE.begin();
  digitalWrite(LED_BUILTIN, HIGH); // Never happens :(
}

void loop() {

}

Steps to reproduce the behavior:

  1. Write a sketch to include both STM32duinoBLE and STM32FreeRTOS libraries
  2. Upload sketch.
  3. See that it hangs on BLE.begin()

Expected behavior
Usable library with using FreeRTOS features

Desktop (please complete the following information):

  • OS: MacOS
  • Arduino IDE version: PlatformIO Core CLI v 6.1.11
  • STM32 core version: 2.6.0
  • STM32duinoBLE version: 1.2.5
  • STM32FreeRTOS version: 10.3.2
  • Upload method: STLink

Hardware (please complete the following information):

  • Board Name: P-Nucleo WB55
@jayadamsmorgan jayadamsmorgan added the bug Something isn't working label Nov 13, 2023
@jayadamsmorgan
Copy link
Author

I would also like to say that I am very happy to help on that bug if somebody points me to right direction

@fpistm
Copy link
Member

fpistm commented Nov 14, 2023

Hi @jayadamsmorgan
When you include STM32FreeRTOS, it changes the way IRQ and some other ressources are managed.
As stated in the FAQ .4: https://www.freertos.org/FAQHelp.html
If a FreeRTOS API function is called before the scheduler has been started then interrupts will deliberately be left disabled, and not re-enable again until the first task starts to execute. This is done to protect the system from crashes caused by interrupts attempting to use FreeRTOS API functions during system initialisation, before the scheduler has been started, and while the scheduler may be in an inconsistent state.

BLE uses IRQ and uses systick which is now managed by FreeRTOS.
So this is normal. You have to start the scheduler and properly configure BLE in a task context. FreeRTOS can also required some configuration depending of your use case but it is up to user to properly configure this.

@fpistm fpistm closed this as completed Nov 14, 2023
@fpistm fpistm added question Further information is requested and removed bug Something isn't working labels Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants