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.

Regarding memMax and memAlo - TI CC2540 - BLE 1.4.0

Other Parts Discussed in Thread: CC2540

Hi,


When using heap profiling with OSAL_MEMMTRICS=TRUE, intermittently, the values memMax and memVal appear

to be having their MSB set resulting in a larger value than what is set using INT_HEAP_LEN. However, if we discard

the MSB and consider the remaining bits, the values of memMax and memAlo remain within INT_HEAP_LEN. This is

happening with TI CC2540 BLE 1.4.0 SDK. With respect to this, I notice that there some house-keeping information

in the form of "memory in use" wherein OSALMEM_IN_USE(0x8000) is being used for toggling certain values in

OSAL_Memory.c. Based on these, here are my questions :

  1. Is it an expected behavior to have memMax and memAlo their MSB set under certain circumstances?
  2. If the answer is "yes" for (1), do we need to simply discard the MSB and consider only the applicable lower bits of memMax and memAlo(by masking depending on their maximum possible value - INT_HEAP_LEN)?

Thanks,

Raghavan

  • 1. No, I have never seen this and I use this frequently. I'm not sure what you could be seeing here. I would recommend stepping through osal_mem_alloc when you see this.
  • Hmm, okay. Yes, I am trying to do that. But, as I said, the problem is that it doesn't happen *consistently*.
    I saw some 2-3 times this behavior back to back the other day and today, I am trying to reproduce this to be able
    to step through OSAL_memory.c code.

    Raghavan
  • Hi Tim,

    I would like to give some more context to this MSB-getting-spuriously-set issue we are facing with memMax and memAlo.

    We are recording the memMax and memAlo values and packing into the scan responses, advertisements, and
    other kinds of BLE messages that are sent over the air as well as over the UART interface. Over a period of 30 minutes
    or so, typical BLE operations(scanning, advertising, and connections) occur. Before and during this 30 minutes of
    BLE operations, memMax and memAlo values appear to be sane, that is, well within the range of INT_HEAP_LEN(1610).
    However, in some cases, after this 30 minutes activity, memMax and memAlo are seen having their MSB *spuriously* set
    resulting in huge value(greater than INT_HEAP_LEN) - so, if we discard the MSB and just consider the remaining
    bits, memMax and memAlo values become meaningful being lesser than INT_HEAP_LEN.

    Now, with the above information, I hope you have a better view of in what context we are seeing this
    MSB-getting-spuriously-set anomaly. With this, can you tell us why this could be happening? And please
    let us know if any other information is required in this regard.

    Best,
    Raghavan
  • As stated, this still shouldn't' be occurring and I would guess that you additions to send the variables over the air are causing some problem. I would recommend adding a breakpoint around code that checks the value of one of the variables to see what is setting it high, i.e. on the NOP here:

    if (memMax > INT_HEAP_LEN)
    {
    asm("NOP");
    }