Problem with advertising when using HAL_Delay in main funcion.

[Kolab]

Hello! I am trying to control a set of leds through bluetooth. In the main function ,after the main task I call the function that manage the leds and into this function there is HAL_Delay that has to receive its argument from bluetooth. The problem starts when I try to find the board using ST BLE Sensor app :

1) It takes a remarkable time to appear on the devices' list. When I connect successfuly to board then appear the second issue:

2) when I send the data (write characteristic) it also delays. How could I solve these delays?

[Remi QUINTIN]

​If you started from the BLE_p2pserver application, note that the advertising only lasts for 30s max. Then you have to reset the board to relaunch the advertising phase.

Point 2 is hard to explain. Is there any HAL_delay in the code executed to retrieve the data?

[Kolab]

Hello! Remi I left the advertising in default (INITIAL_ADV_TIMEOUT =60s).

About the point 2 I would like to specify that I am sending the data from the phone. And using debug I noticed that the program achieves case CUSTOM_STM_WRITE_WRITE_NO_RESP_EVT: in p2pserver_app.c only after the end of execution of HAL_Delay . I get such as code (called in by a function in main):

for(pos=0;pos<100;pos++)

{

...

HAL_Delay(100);

}

it means that my data will appear in pPayload pointer(p2pserver_app.c) after 100*100 ms, that is, 10s :persevering_face:

[Remi QUINTIN]

​Strange I do not have this code in my p2p_server_app.c file. Did you add it?

What version of the CubeWB FW pacakage are you using?

[Kolab]

for(pos=0;pos<100;pos++)

{

...

HAL_Delay(100);

}

is my code. Not of STM.

With "CUSTOM_STM_WRITE_WRITE_NO_RESP_EVT: " I meant " P2PS_STM_WRITE_WRITE_NO_RESP_EVT: "

[Remi QUINTIN]

Sorry, it is hard to get your point.

If 10s is too long , why don’t you reduce the loop? Though I dont understand while you have such loop in the main code.

I understand you created/added a specific case CUSTOM_STM_WRITE_WRITE_NO_RESP_EVT in the P2PS_STM_App_Notification function in the p2p_server_app.c file.

Then the characteristic should be updated.

This is what happen when using the BLE-p2pserveur project with the ST_BLE_SENSOR application on your mobile, writing the on/off characteristic (case P2PS_STM_WRITE_EVT) and the light on the board is lighting on/off almost instantaneously.

[Kolab]

I am controling the blinking time of a set of leds and I want to send to HAL_Delay any time that I want. Reducing this time will limitate what I am trying to do. I have the loop in main by choice . Firstly I wrote it in p2p_server_app.c , but in both places the result is the same: the string that I send from the phone is received by the board only after the system leaves the loop, that is, the system is getting stucked in this loop and at this time cannot receive data from bluetooth.

[Remi QUINTIN]

Ok so you are suggesting the issue may be coming from the HAL_delay function? Something like a blocking of all other events or interrupts preventing the execution of related callbacks to retrieve data?

[Kolab]

yes, but I am not sure reason why I asked.

[Remi QUINTIN]

Just got a hint from an expert regarding this BLE stack.

In fact, all BLE events are managed via an interrupt from the IPCC . They are then forward to a background process which calls the related callbacks.

Hence this background process will only resume its execution once the loop is over.

So one possibility is to raise the priority of the background process or lower the priority of the loop.