On Thu, Mar 29, 2018 at 10:27:36PM +0530, Aditya Xavier wrote: > Thanks for the tip. Would try that too.. > > However, I have tried few variations to check the BLE side ( whether it was > responsible for truncating ) > > 1. I am able to send the same message using encoding only.. i.e. if I trigger > the same using a button to send over ble. > i.e. BLE Connection, Button -> Encoding -> BLE Output, works. > > 2. The method which receives the char * data, itself receives a truncated > value. > BLE Connection, BLE Incoming -> Decoding -> Encoding -> BLE Outgoing, > does not work. Truncation. > > 3. I am able to send the same message using encoding only.. i.e if I trigger > only the encoding method after receiving a message over BLE. > i.e. BLE Connection, BLE Incoming -> Encoding -> BLE Outgoing, works. > > This kinda makes me feel that it should be a memory issue when its BLE + > Decoding + Encoding. With or without using mbuf / mbuf_pool > > Let me know if you require to see the code, I can write another small test > app for you.
I think I understand the sequences you described. I'm afraid I don't have a good answer. Are you checking the return code of the encoding function? If the system is running out of mbufs during encoding, the function should return `CborErrorOutOfMemory`, and the mbuf chain will be partially filled. If you are running in gdb, another way to check for mbuf exhaustion is: ``` p os_msys_init_1_mempool ``` and look at the `mp_min_free` value. If it is 0, that means the pool has been exhausted at some point, and it is likely that some allocations have failed. You can also just try increasing the number of mbufs in the system: ``` newt target amend <target-name> syscfg=MSYS_1_BLOCK_COUNT=16 ``` (assuming you are currently using the default value of 12; adjust accordingly if not) Chris
