Integration of an existing project into the sequencer (UTIL_SEQ)?

[TomC]

I wish to add BLE functionality to an existing project on an STM32WB55. It appears that use of the sequencer (UTIL_SEQ) is encouraged if not mandatory for employing the BLE coprocessor on the WB55.

My understanding of the sequencer is that it's simply an optimized while loop and so any existing interrupts (Timers & DMA) I have utilized will continue to function as normal and I should take what's running in my current super loop (while(1) loop) and slot them into functions that I then register as tasks and set with the sequencer.

Are the assumptions I've made regarding interrupts correct and is the approach of integration I have described straight forward and reasonable?

Here is a list of resources I've found relating to use of the sequencer with the STM32WB55:

STM BLE Tutorial

Building wireless applications with STM32WB Series microcontrollers

STM32WB Bluetooth® Low Energy (BLE) wireless interface

STM32WB – BLE SW Application Architecture

[TomC]

Okay thank you Christophe I will preference use of the sequencer.

Finally, and please advise me if I should move this into a new post, I am finding that if I register several tasks with my sequencer in a project that utilizes the BLE peripheral, configured as per this tutorial, my device (STM32WB55) will no longer advertise consistently to either an Android or iOS device running the "ST BLE Sensor" mobile application. I find that if I register fewer tasks that the device will advertise reasonably well and am also able to reliably get example projects working.

All of my tasks are of the same priority (1) and I believe the BLE Advertisement Request, by default (CUBEMX), is the highest priority (0). I was wondering if increasing the number of registered tasks will indeed affect the BLE advertising behaviour or if it's perhaps the contents of one or more of these tasks. My understanding is that the BLE Advertisement, by default (CUBEMX), is triggered by an interrupt and advertises for 60 seconds at a time, and that it will continue to interrupt and advertise while ever the program is running.

It's not obvious to me the mechanism by which these tasks which, I believe, are of lower priority than the BLE advertisement, affect its behaviour. Furthermore, if the BLE Advertisement executes only once initially, I am not seeing evidence of this behaviour either. Additionally, if the device is able to advertise I receive the error message "Error during the connection with the node [device name]".

[TomC]

Re: BLE Advertising fails when adding tasks.

This was caused by using the same task IDs for my own tasks as were used by the BLE tasks in the code generated by CUBEMX. I believe the BLE tasks were using values 0 & 2, so my own task IDs are all 20 or greater just to be sure.

[AM.12]

Hello @Community member​ , @Christophe Arnal​ .

I am facing a problem related to this post, I was searching for the solution and I came across this post.

I am working on STM32WB55 custom board. I have configured it in STOP2 low power mode.

when the device wakes up due to EXTI if I try to use HW_TS_Start or UTIL_SEQ_SetTask. device Hangs up.

Can you suggest me what I am missing in configuration

[vishalkeshavamurthy]

Hi Cristophe, visiting this thread very late, but I was wondering if I could run a single large task that runs for about 30 seconds in the sequencer without affecting the BLE functionality. 

I am trying to tack on BLE functionality to an existing product that, previously ran once and put it itself to deep sleep. Can I make a single task that sleeps in the end and make it a part of the sequencer? 

[vishalkeshavamurthy]

Hi Tom, I know its been a while since you tackled this topic, but just wanted to know if setting the task IDs resolved the issue you were experiencing? 

Also any idea if I can just run a single task that has a run time of over ~30s and put myself to sleep without affecting the BLE functionality  in that 30s timespan ? 

[TomC]

Hi vishalkeshavamurthy,

In your case I'm not sure how to, when using the sequencer, prevent the task you describe (30 secs) from hogging the CPU. Allegedly the sequencer has a round robin mechanism that prevents this from happening? @Christophe Arnal @Remi QUINTIN