Ich versuche hier das IDB05A1 BLE Modul von ST zu betreiben, scheitere
z.Z. aber an einem mir nicht ganz einleuchtenden Problem.
Aufbauend auf den ST Beispielprogrammen (ohne RTOS) funktioniert das
tiptop, wenn ich über den MXCube aber das FreeRTOS hinzufüge und den BLE
Chip initialisieren will, scheint er sich bei einem HAL_Delay() aufrauf
aufzujängen.
1 | /**
|
2 | * @brief Reset BlueNRG module.
|
3 | *
|
4 | * @param None
|
5 | * @retval int32_t 0
|
6 | */
|
7 | int32_t HCI_TL_SPI_Reset(void)
|
8 | {
|
9 | HAL_GPIO_WritePin(HCI_TL_RST_PORT, HCI_TL_RST_PIN, GPIO_PIN_RESET);
|
10 | HAL_Delay(5);
|
11 | HAL_GPIO_WritePin(HCI_TL_RST_PORT, HCI_TL_RST_PIN, GPIO_PIN_SET);
|
12 | HAL_Delay(5);
|
13 | return 0;
|
14 | }
|
Und zwar wird der erste call noch ausgeführt, wenn ich aber beim zweiten
HAL_Delay(5) einen BP setzte und dann mittels Step-Into Debug Funktion
da hineinspringen will, hängt sich die Geschichte auf.
HAL_Delay() macht nichts weiter als eine gewisse Anzahl an HAL_Ticks zu
warten
1 | __weak void HAL_Delay(uint32_t Delay)
|
2 | {
|
3 | uint32_t tickstart = HAL_GetTick();
|
4 | uint32_t wait = Delay;
|
5 |
|
6 | /* Add a period to guaranty minimum wait */
|
7 | if (wait < HAL_MAX_DELAY)
|
8 | {
|
9 | wait++;
|
10 | }
|
11 |
|
12 | while((HAL_GetTick() - tickstart) < wait)
|
13 | {
|
14 | }
|
15 | }
|
Kann es sein, dass hier irgend ein Konflikt mit dem RTOS vorliegt?
Vielleicht hat ja jemand schon was ähnliches mal gemacht.
