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.

CC2642R: Bluetooth requests ATT memory, API GATT_bm_alloc

Part Number: CC2642R

Hi Team,

When we, as the server, call the application memory interface ‘void *GATT_bm_alloc(uint16 connHandle, uint8 opcode, uint16 size, uint16 *pSizeAlloc)’ before ‘Send an ATT Notification/Indication’:

1). When the requested size is set to GATT_MAX_MTU (0xFFFF), the requested memory is 20 bytes. Why would this happen? Regardless of the MAX_PDU_SIZE set in our syscf, and the fact that MTU request initiated by the client is more than 23 bytes, the final memory requested is 20 bytes.
2). Is the memory allocated by this interface not limited by MAX_PDU_SIZE? When the size is set to 100/200/500, the MAX_PDU_SIZE set in syscfg is 69, and finally the corresponding memory 100/200/500 can be obtained.

Kind regards,

Katherine

  • Hi Katherine,

    1- GATT_bm_alloc is configured to allocate the number of bytes specified by the parameter size, plus an header (whose actual size depends on the opcode). By passing an incoherent value (0xFFFF bytes corresponds to 63 kBytes!), the calculation overflows and you obtain an erroneous value.
    To be clear, even without this calculation overflow, the system would not be able to allocate 63 kB from the heap, and would always returns an error.
    The size allocated should be chosen based on the needs, not be defaulted to its maximum.

    2- The PDU size and the ATT packet size are NOT related. Actually, there are mechanisms to split and reassemble ATT packets not fitting the MTU.

    I hope this will help,

    Regards,