CC2340R5: System Stack Overflow

Hi Clément,
First of all, thank you for your reply. I still have some questions that I want to understand clearly.

1. When my System Stack does not have Stack Overflow, that is, there will be a piece of information composed of 0xA5 starting from 0x20008CE0 in the picture. Does this mean that I have not used the area where 0xA5 appears?

2. When I make a Bluetooth connection and use Notify, I find that the addresses before 0x20008CE0, such as 0x20008C50 to 0x20008CDF, will change from the original 0x00 to written data. Does this mean that the System Stack overflow overflows? Is the data written forward?

3. Following the first question, if System Stack is writing, I found that it will write from the bottom of the address first, so some bytes starting from 0x20008CE0 will appear as 0xA5 when they are not used. This understanding is correct. Yes, then when Stack does not need to use so much, will the data return to 0xA5 after release?

4.What is the effect of the Validate at task switch in SysConfig > FREERTOS > FreeRTOS > Stack Overflow Checking? and What is the difference between this and the default 16-byte sentinel mode? Is there any relevant documentation I can refer to?

Hi Ryan, 

Ryan Li said:

1. When my System Stack does not have Stack Overflow, that is, there will be a piece of information composed of 0xA5 starting from 0x20008CE0 in the picture. Does this mean that I have not used the area where 0xA5 appears?

The "0xA5" values are usually canary meant to help the developers (and tools) to detect stack overflow. You can assume the the area filled with 0xA5 has not be touched - even if you cannot be 100% sure as if you are very unlucky you may have basically write 0xA5 to this area (in practice. I have never experienced this case). 

Ryan Li said:

2. When I make a Bluetooth connection and use Notify, I find that the addresses before 0x20008CE0, such as 0x20008C50 to 0x20008CDF, will change from the original 0x00 to written data. Does this mean that the System Stack overflow overflows? Is the data written forward?

I am not sure. What you describe could indeed a stack overflow. This could also be simply some regular dynamic allocations. Are the tools reporting any issue or malfunctioning when experience this?
If you increase the stack size, do you experience the same? (if yes, then I believe this is not a stack overflow) 

Ryan Li said:

3. Following the first question, if System Stack is writing, I found that it will write from the bottom of the address first, so some bytes starting from 0x20008CE0 will appear as 0xA5 when they are not used. This understanding is correct. Yes, then when Stack does not need to use so much, will the data return to 0xA5 after release?

Overwriting the canary (0xA5) should be considered as a stack overflow - i.e. you should increase the stack to avoid this. 
The canary is not reverted after being overwritten. This ensures a stack overflows can be detected even after pausing the program execution. 

Ryan Li said:

4.What is the effect of the Validate at task switch in SysConfig > FREERTOS > FreeRTOS > Stack Overflow Checking? and What is the difference between this and the default 16-byte sentinel mode? Is there any relevant documentation I can refer to?

I'd recommend referring to FreeRTOS documentation - https://www.freertos.org/Documentation/02-Kernel/02-Kernel-features/09-Memory-management/02-Stack-usage-and-stack-overflow-checking#stack-overflow-detection---method-1 

Best regards, 

Hi Clément,
Thank you for your reply. I have increased the system stack to 2048, but after a few days of testing, I found that CC2340 still crashes.I tested 50 CC2340s and 3 crashed in 10 days.

1. I would like to ask if CC2340 can call the Bluetooth function to disconnect the connection when it is not connected. Or when CC2340 is connected and notifying, if the connection is suddenly disconnected or other interruptions occur, will it cause a crash?

2.I am wondering if it is not recommended to call the function directly in the Bluetooth framework, even if it can run successfully in the case BLEAPPUTIL_ADV_START of app_peripheral.c in the example project, as shown in the attached picture, BLEAppUtil_invokeFunctionNoData is still required.

Hi Clément,
Thanks for your answer, I will do more detailed testing.

I have another question. During the test, I found that if I use UART2_write to transfer data while using Bluetooth Notify, CC2340 will crash within two hours. As shown in the attached picture, when I change UART2_writemode from The situation seems to improve when BLOCKING is changed to NONBLOCKING. I want to ask why?

Hi Ryan, 

On the "UART blocking" topic - Your observation is expected. Blocking calls impact the timing. The Bluetooth stack is extremely timing sensitive, so I would generally recommend to avoid such blocking calls. 

Best regards,  

Hi Clément,
Sorry I overlooked an answer, I'm currently using version 7.40.00.64 of the SDK

1.If UART2_readMode is callback, blocking callback will not be used. Am I right?

2.But I added sem_wait() after UART2_read(). Will this affect Bluetooth?

Hi Ryan, 

Ryan Li said:

I'm currently using version 7.40.00.64 of the SDK

I would highly recommend migrating to the newest SDK (8.40 as of today) as several bugs have been addressed. 

Ryan Li said:

1.If UART2_readMode is callback, blocking callback will not be used. Am I right?

2.But I added sem_wait() after UART2_read(). Will this affect Bluetooth?

1. Correct!

2. If the sem_wait() affects the execution of the task interfacing the Bluetooth task, then you should for sure review the impacts. For reference, adding a "sem_wait()" after UART2_read(), is technically really close as setting the UART in blocking mode so behavior may not change. 

Best regards, 

Hi Clément,

1. I would like to ask, what bugs are fixed in the SDK version 8.40.00.61? Because I checked the latest news in the Release Note, it seems that there are only descriptions of fixing some bugs, but no more detailed fix information, so I can't Determine if it is related to the situation I am experiencing

2. If I don't use sem_wait(), how can I wait for Rx to receive data?

Hi, 

Ryan Li said:

1. I would like to ask, what bugs are fixed in the SDK version 8.40.00.61? Because I checked the latest news in the Release Note, it seems that there are only descriptions of fixing some bugs, but no more detailed fix information, so I can't Determine if it is related to the situation I am experiencing

Please reference the BLEStack release notes for details. 
You can also refer to the Comprehensive List of Fixed Issues - fixed issues in SDK 8.40 can be found in the TI BLE5-Stack Release Notes

Ryan Li said:

2. If I don't use sem_wait(), how can I wait for Rx to receive data?

The data is passed in a callback. The solution is then to trigger the handling of the data - using BLEAppUtil_invokeFunction() or similar - from the callback itself. 

I hope this will help,

Best regards,

Hi Clément,

I seem to have found the reason why it is stuck in a loop. After testing today, I wrote a lot of data and enabled Notify after the Bluetooth connection, and then suddenly lost the connection, which caused GATTServApp_ProcessCharCfg in SimpleGattProfile_setParameter() to return 0x16. That is, it is currently in the pending state and then enters a loop. 

1. I tested SDK versions 7.40 and 8.40 and both have this problem. But I checked the fix records you provided. Are there any issues similar to my current situation in EXT_EP-11778 and EXT_EP-11752? The situation is different from these two topics?

2. The original SDK added while(1), I guess it was to facilitate debugging for users, so if it is removed, will it affect the Bluetooth task? Or if while(1) is not used, Is there any better solution? For example, if the response is not successful, execute GATTServApp_ProcessCharCfg again.

Hi,

Ryan Li said:

1. I tested SDK versions 7.40 and 8.40 and both have this problem. But I checked the fix records you provided. Are there any issues similar to my current situation in EXT_EP-11778 and EXT_EP-11752? The situation is different from these two topics?

I don't belive the tickets mentioned are related.

• EXT_EP-11778 is related to a "blePending" error returned in cases where a lot of notifications are sent. It is not related to connection lost. 
• EXT_EP-11752 will create a memory leak when a connection is terminated. 

Ryan Li said:

2. The original SDK added while(1), I guess it was to facilitate debugging for users, so if it is removed, will it affect the Bluetooth task? Or if while(1) is not used, Is there any better solution? For example, if the response is not successful, execute GATTServApp_ProcessCharCfg again.

The "while(1)" you refer to was actually - per my personal opinion - a bad way to handle the error. As you mentioned it was making debugging easy but it was pretty dramatic for the system as the system was basically crashed. 

Best regards,  

Hi Clément,

Thanks for the instructions. I will comment out while(1) and test again to see if there are other exceptions.
I also want to ask two things

1. Can I set the path of commom -> Profiles -> simple_gatt_profile.c to the simple_gatt_profile.c in the project? I found that even if I reset the path, it will still read the simple_gatt_profile.c in the SDK instead of the one in the project.

2. SDK 8.40 seems to have a new MCUBoot feature. Does this mean adding a Bootloader in front of the Application? If so, can I use UART to update the program in the Application area, like a ROM Bootloader?

Hi Ryan, 

Could you please open a new thread to continue the discussion? 

I'll be out of the office for some time and won't be able to follow-up. 

Appreciate your comprehension and thank you for the quality of the discussion so far. 

Best regards,