CC2652R: Memory Corrupting

Kenneth Thomas

Part Number: CC2652R

Tool/software:

Hello,

So we are facing an issue with our memory getting corrupted. Our code was built upon a project_zero example and I was wondering if using the posix library for semaphores, threads, mutexs and conditions would affect our ability to dynamically create these tools in our code. We also were wondering where the initialization of these tools had to be done for example whether its before or after BIOS_start, before or after the construction of the project_zero task or even if it could be done statically.

Thanks,
Kenneth Thomas

over 1 year ago

0 Ryan Brown1 over 1 year ago

TI__Guru**** 218057 points

Hello Kenneth,

The TI-POSIX User's Guide contains information as to what POSIX APIs are allowed in the calling context of main vs tasks. There is also some POSIX Support information in the BLE5-Stack User's Guide.

Can you please explain what divergences from the project_zero you suspect could be causing the memory corruption? I also recommend reviewing the Debugging Guide for further memory debug suggestions.

Regards,
Ryan

0 Kenneth Thomas over 1 year ago in reply to Ryan Brown1

Prodigy 250 points

Hey Ryan,

Thanks for the POSIX API guide. I don't think that was the problem. So a code diverges quite a bit from the project_zero but it uses its BLE stack for ble connections and OAD we have another detached thread that's being called from ProjectZero_taskFxn that runs our Application. Our Application has its own message queue and it seems that as the message is being handled some of the data members in the message object loses its value and is now using an address value. We've tried many things like switching from shared_ptrs to normal pointers, checking the stack sizes of the tasks and system stack, using the heap metrics and changing the place of initialization of stacks/semaphore to be done in main and then also tried to move it into the ProjectZero_taskFxn. Thanks to the documentation you provided in your last post it seems to be a NMI exception. I read in this forum :https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1387403/cc2652r-bluetooth-stack-does-not-work-when-memory-allocations-are-made-before-icall_createremotetasks/5306148?tisearch=e2e-sitesearch&keymatch=heap%2525252520corruption#5306148 that there might be an error in the API around the heap managing. If you have any more ideas of what we can try that would be great.

Thanks,
Kenneth

0 David over 1 year ago in reply to Kenneth Thomas

TI__Genius 15575 points

Hello Kenneth,

Thanks for reaching out. Could you please share more details on what you have added to project_zero? To make sure I understand, are you creating a new thread from ProjectZero_taskFxn? May I know what is this thread doing? Is it ICall Register (take a look at this link)? Regarding the previous thread referring to the ICall_allocate(), we are still looking into it and we will come back to you soon but I think we need to understand better your case first.

You could monitor the stack using the TI-RTOS Object Viewer and the heap following the guide Debugging Common Heap Issues in order to see if there is a evidence of memory leakage.

BR,

David

Bluetooth®︎

Bluetooth forum

CC2652R: Memory Corrupting