Hi Aditya, On Sun, Apr 1, 2018 at 3:51 PM, Aditya Xavier <adityaxav...@me.com> wrote: > Hi Andrzej, > > PFB my the test code, this is a torn down version of the code we were trying > to do. > > However it should be good enough for you to understand the objective and the > issues at hand. > > I did not personally try the code myself, I would be able to do so and let > you know the same tomorrow.
I checked the code and there are some issues wrt to mbuf handling which can cause problems. Firstly, I don't see where you actually initialize cbor_codex_mbuf with proper mbuf as you neither received it from somewhere or call os_msys_get()/os_mbuf_get() to get it from a pool. Calling net_buf_simple_init() does not work here since it only initializes existing mbuf and you probably should not use it at all unless you're using this code for mesh. In case of mesh you can get valid mbuf by using NET_BUF_SIMPLE(). I assume this looks a bit different in your app as this sample app will most likely crash during startup. Secondly, this probably causes data truncation: cbor_decode_action((char *)cbor_codex_mbuf->om_data, cbor_codex_mbuf->om_len); Basically this way you pass contents of first mbuf in chain to decoding function, not complete chain. Internally this calls cbor_read_flat_attrs() but when working with mbufs you should use cbor_read_mbuf_attrs() instead and pass mbuf instead of its data. > Thanks, > Aditya Xavier. Best, Andrzej > > >> On 31-Mar-2018, at 3:06 PM, Andrzej Kaczmarek >> <andrzej.kaczma...@codecoup.pl> wrote: >> >> Hi Aditya, >> >> On Sat, Mar 31, 2018 at 5:51 AM, Aditya Xavier <adityaxav...@me.com> wrote: >>> Increasing MSYS_1_BLOCK_COUNT to 30 gets it to work, but if I increase it >>> to 40 it doesn’t. >>> Block size being 110. >>> >>> Any reasoning behind this pattern? >> >> This is strange. Can you post some piece of code to show how you handle this? >> >>> Also what would is behaviour of os_mbuf_free? Do I need to re init it again? >> >> Not sure what you mean by "reinit". Calling os_mbuf_free() releases >> mbuf back to pool and it should no longer be used. You should call >> os_mbuf_get() or os_msys_get() to get new mbuf from appropriate pool. >> Also, if your CBOR stream exceeds size of block then you will have >> chain of mbufs which should be freed using os_mbuf_free_chain() >> instead. Basically, if you're not sure whether your mbuf is just a >> single mbuf or chain of mbufs, you can always use os_mbuf_free_chain() >> instead of os_mbuf_free(). >> >>> Sent from my iPhone >>> >>>> On 30-Mar-2018, at 1:58 AM, Christopher Collins <ch...@runtime.io> wrote: >>>> >>>>> 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 > >
