freeRTOS xTaskResumeAll lockup when using BLE and TWI

[Rambooka]

Hi…

I am using freeRTOS V10.0.0 release

I am using nRF52820 + SDK V17.0.2 with SD112 V7.2.0 along with tickless idle as this is a battery based product…

When my application is just talking over the IIC bus it works perfectly   ISR Priority = 3
When my application is just talking over BLE it work perfectly               ISR Priority = 3

When I talk over IIC bus and BLE at the same time, somethings gets stuck and the watchdog resets to product… Not a great user experience !!

Here is my investigation
When the firmware freezes, I then paused the CPU…
I see that the CPU is stuck in the freeRTOS tasks.c API xTaskResumeAll() in an endless loop inside while( listLIST_IS_EMPTY( &xPendingReadyList ) == pdFALSE )

When I single step the CPU, the while loop keeps on going around and around
xPendingReadyList.uxNumberOfItems remains at 1, so pdFALSE condition never happens 

I have looked here: endless loop in function xTaskResumeAll which talks about interrupt priorities clashing…  I have made all ISRs that I use to Priority = 3 except for RTC1 => 7 (see attached picture), as this problem could be due to corruption of the freeRTOS structures due to different ISR priorities 

What I have done to fix the problem
I added a counter in the while loop that will exit after counter reaches # of tasks created
This works well and my application now works perfectly when IIC and BLE activity happen at the same time

uint8_t retry = 0;
while( (listLIST_IS_EMPTY( &xPendingReadyList ) == pdFALSE) && (retry < uxCurrentNumberOfTasks) ) {
   …
   retry++;
}

Thanks for any Help
Ray

[Rambooka]

here is the call stack

When my App locks up, I pressed the pause button and took a screen capture...

the stack trace shows 0x1dd28 , so I also attached screen capture of that disassembly code 

Hope this helps

[Rambooka]

Hi...

I have been running Stack Overflow Detection - Method 2 for a few weeks now and the API  vApplicationStackOverflowHook() has never been called 

I posted a simular question freeRTOS forum here and they are suggesting the problem i am facing is due to incorrect interrupt priorities. Such that one ISR is in the middle of adding an event to a queue  and another ISR occurs and writes an event to the same queue... which results in the queue getting corrupted.

I am using all the settings for ISR priorities that nordic setup for the example BLE UART App.

Do the ISR priorities I posted initially look correct ?

[Susheel Nuguru]

I can see that SPI and COMP are using higher app (legal) priorities. Hard to say just looking at the priorities if they are causing a deadlock. It might help if you show what you are doing in the that ISR (or app callbacks from the ISR)

[Rambooka]

The SPI and COMP are being used in polling mode.... so there should be no problem

[Susheel Nuguru]

Rambooka said:

I have been running Stack Overflow Detection - Method 2 for a few weeks now and the API  vApplicationStackOverflowHook() has never been called 

This is useful for this does not guarantee that it will catch the stack overflow. I still suggest you to increase the stack sizes for your threads just to do some experimentation. I understand that you are using nRF52820 and RAM might be limited in your case.