Problem with advertising when using HAL_Delay in main funcion.

​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?

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:

​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?

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: "

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.

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.

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?

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

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.

My wording may be no clear. As there is no operating system running on the STM32WB (it is a basic bare metal implementation), the only way to interrupt a code execution is an interrupt.

The sequencer (a big while loop) was introduced to cope with this lack of real time OS. You can use the wait_event functionality to let some execution time to another task while waiting for an event.

Now you can understand that the complete BLE event process is not performed only under interrupt. One part is done in a task registered to the sequencer with a certain priority level.