This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC2640R2: Strange behaviour of BLE once SRAM increases

Part Number: LAUNCHXL-CC2640R2
Other Parts Discussed in Thread: CC2640R2F

Hi,

I am working on my custom application based on project zero example code. I was adding different peripherals to the code and adding my code, when I realised that the Bluetooth radio of the device is not working as expected. As per a different thread by me, I was unable to send data packets if I increase the MTU size to 100 or more bytes. It was working only when the MTU was increased to 60 or 70 bytes. If I set it higher than that, the Bluetooth would just keep loading (on my mobile app) and would eventually disconnect.

All in all, there were four distinct strange behaviour that the BLE radio displayed:

1. Unable to increase the MTU size to >100 bytes.

2. Sometimes, even when the connection is established, the device disconnects without any reason.

3. Sometimes, when connect to the device, then itself the app keeps loading and eventually disconnects.

4. Sometimes, I received ATT flow control error (opcode 0x10) on the UART log and the device was unable to connect to my mobile. Very similar to this thread . The solution in the thread didn't work for me as I was not using any extra task in my application.

I was using nRF app for this. All the above situations happened sometimes and not always that led me to believe that this was something with memory.

The SRAM being allocated at this time was ~13,100 bytes.

After several days of dealing with this, I tried reducing the memory footprint of my application. There is a UART_Log module that is present in the projectZero example by default. I was using it to log data on UART trace. I disabled it by removing the UARTLOG_ENABLE predefined symbol. The SRAM got reduced to ~11,900 bytes and all of the above "stability" issues with Bluetooth were now gone. I was able to send >100 bytes via BLE and never did it lag or load to the point that it disconnected.

My question is, Was RAM shortage the only issue that was causing the above issues? Or was it something else that was solved by increasing SRAM (free area) that indirectly solved the above issues?

Am I limited to less than  ~12.8k or 12.9k of SRAM usage at code startup to make sure that the BLE is stable and works properly?

I apologise if you didn't understand the issue, it is very specific. It would have been easier for me to explain it to someone rather than writing it here.

  • Hi,

    To me it is not surprising to see an issue related to RAM shortage. This could lead to a stack corruption or an head shortage and lead to the behavior you have experienced. That being said, with the limited information provided I cannot be sure. I recommend to leverage our ROV (see the debugging guide for details) in order to look at the stacks and heap.

    CC2640R2F has 20 kB of SRAM. By reducing the RAM used, the heap available for the application get increased. 

    Let us know if you need further help,

    Best regards,