Combining BLE Application with Existing Project

[JakBSIP]

Hi all,

I have been working on a Nucleo 68 board to develop firmware for my project. I have been working in parallel on two projects - one was purely hardware control - read/write to/from various peripheral devices (UART with IT and I2C DMA and External Interrupts). I am very happy with that side and it works perfectly. The other project was pure BLE application, which I have now written and on its own it works perfectly. It is a BLE client that simply gets the data out of a peripheral sensor.

I am however now stuck trying to combine the two projects together. I have seen a similar post https://community.st.com/s/question/0D53W00000dOycq/integration-of-an-existing-project-into-the-sequencer-utilseq however it did not solve the issue. And actually in that post @Christophe Arnal​ suggests that interrput handlers should remain unaffected by the addition of the sequencer into the project.

These are my observations:

1/ Both projects on their own work perfectly - the same configuration file for both.

2/ Simply combining the projects was expected to fail as the main loop should be wrapped into a function registered to the sequencer, so no surprise there.

3/ However when removed all the other code and just left the BLE Application, the Sequencer and one External Interrupt the interrupt is not registered (though SW3 button).

so this works:

MX_GPIO_Init();

while (1) {

}

.

.

.

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {

if (GPIO_Pin == SW3_Pin) {

HAL_GPIO_TogglePin(LED_RED_GPIO_Port, LED_RED_Pin);

}

}

but this doesn't:

MX_GPIO_Init();

MX_APPE_Init();

while (1) {

MX_APPE_Process();

}

.

.

.

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {

if (GPIO_Pin == SW3_Pin) {

HAL_GPIO_TogglePin(LED_RED_GPIO_Port, LED_RED_Pin);

}

}

I guess that would be the first step towards solving the problem. I ahve no problem shoving the entire contents of my while(1) loop into a task, but I don't see a point if a simple interrupt is not working (and my UART runs on interrupts, I2C is signalled through interrupts, and user button also uses those).

When using a debugger - I see that the while(1) loop with MX_APPE_Process() is happily running but the interrupt is never caught.

What could be going wrong here?

Many thanks!

I'm using STM32CubeIDE 1.7.0

STM32CubeMX 6.3.0

and the lastest FUS and BLE Stack from Github: v1.12

[Scott Löhr]

This is such a nebulous question, like basically asking someone to sit down with you and pair program and help you debug this merge. It sounds like at least one, if not both, of your perfectly working projects are not running by the Sequencer or other RTOS, and yet you want the two merged projects to be working perfectly by the Sequencer. So I would recommend you to first get both of your projects separately running perfectly by the Sequencer and then chose one and merge the other in, piece by piece, at every stepwise merge, keeping it running perfectly.

[JakBSIP]

@Scott L�hr​  Thank you, appreciate the high level approach to the problem. While the first two paragraphs do indeed show the full picture which might be overwhelming to some, I have included for that reason an amazingly simple example below with a single interrupt, which I think requires no extra sequencer effort, and yet it fails. So the question is then is there any special way of handling interrupts when using a sequencer, or what else might be failing in this scenario? To me it seems as thought MX_APPE_Process() disables them, since while(1) loop keeps running.

[JakBSIP]

Update:

MX_APPE_Init() disables all interrupts (apart from IPCC and semaphores) through Init_Exti() - why would that be the case? If I comment the line out, my BLE App still runs and now the button interrupt is caught, but then shortly after the system enters a HardFault, so that's clearly not a solution.

So then I cut my application short. After connection I terminate any interaction (i.e. dont go through service discovery) and it all works. But still have to disable Init_Exti() for it to work. And this is an automatically generated function. So:

a) why is it generated?

b) do I not disable it, but rather enable the Exti lines at the end of connection?

 

Update 2:

I think I get the answer from analysing example codes. The specific user interrupts are only enabled after Init_Exti() function. So The workflow would therefore be, I suppose, to go through the MX_APPE_Init() process as usual and then in app_entry.c in the user section to enabled the individual interrupts there, rather than the way Cube_MX does it, in that in enables them before initialising the BLE application.

[JakBSIP]

Update 3 and final:

I have successfully integrated the code. I had to silence the Init_Exti() function. What I would like to know what is the disadvantage of doing so? What can happen if I use this in the Release version? So far for the past 30mins my Application and rest of firmware is running smoothly without issues inclv. of DMA UART interrupt and other EXTI lines.

[Christophe Arnal]

Hello,

This issue has been reported and should be fixed in our next delivery.

The Init_Exti() function is planned to be fixed this way

void Init_Exti( void )
{
 /* Enable IPCC(36), HSEM(38) wakeup interrupts on CPU1 */
 LL_EXTI_EnableIT_32_63( LL_EXTI_LINE_36 & LL_EXTI_LINE_38 );
 
 return;
}

The first line that was clearing all EXTI have been removed as this was overwriting the CubeMx configuration.

The second line should be kept or your product should not be working fine in low power mode.

Regards