Out of memory when creating a characteristic

I am creating the Battery characteristic in a Battery service but I run out of memory (0x04 error) when generating the characteristic.  However, that makes no sense. I have the same set of characteristics for several different health devices, blood pressure, glucose, spirometer, thermometer, heart rate, and scale. Only the glucose and the spirometer run out of memory generating a characteristic. In the spirometer case, the reg cert data list char fails in the DIS but the Battery Service and battery do not and they are generated after the DIS.

WHen I build in Keil, I get the size of code and it is only 41K bytes. This is small compared to most of the BT SIG profile examples. The program runs fine but those characteristics that don't get created are not part of the service table.

I am not sure how to solve this issue or why it even happens.

  • Hello brianreinhold,

    This is likely due to the new characteristics or services exceeding the memory allocated for use by the SoftDevice.
    What does your Section Placement Macros in the Project Options for the common configuration look like?
    Furthermore, exactly which function returned the 0x04 error code?
    Do you have logging enabled? If so, the logger should output a warning / error message if the allocated memory section for the SoftDevice is exceeded.

    Could you also confirm whether or not you have DEBUG defined in your preprocessor defines, like shown in the included image?

    This will make your logger output a detailed error message whenever a non-NRF_SUCCESS error codes is passed to an APP_ERROR_CHECK.

    Best regards,
    Karl

  • Karl,

    I do have logging enabled, and if I do not get a success I print the error code.

    The method giving the error is sd_ble_gatts_characteristic_add()

    Here is my startup log

    <debug> app: Power on
    <debug> app: Main start GHS BT-SIG
    <info> app_timer: RTC: initialized.
    <debug> app: Initial Epoch time 4086774784
    <info> app: Total pages is 256, pg_num is 224 pg_size is 4096
    <debug> app: Number of saved stored measurements in flash 7
    <debug> app: Factory timer reset: Current tick 0  Saved time of flash write 18428
    <debug> app: RAM starts at 0x20002B10
    <info> app: Advertisement is 02 01 06 03 03 44 7F 06 16 44 7F 11 10 01
    <info> app: Scan response is: 03 19 00 04 0F 09 47 68 73 53 69 67 20 47 6C 75 63 6F 73 65 00
    <debug> app: Service initiated
    <debug> app: char val length 8
    <debug> app: Characteristic 0x7F40 initiated
    <debug> app: Characteristic 0x7F43 initiated
    <debug> app: char val length 8
    <debug> app: Characteristic 0x2A52 initiated
    <debug> app: Characteristic 0x7F42 initiated
    <debug> app: char val length 22
    <debug> app: Characteristic 0x7F41 initiated
    <debug> app: Service initiated
    <debug> app: char val length 11
    <debug> app: Characteristic 0x7F3D initiated
    <debug> app: Service initiated
    <debug> app: char val length 8
    <debug> app: Characteristic 0x2A23 initiated
    <debug> app: char val length 23
    <debug> app: Characteristic 0x2A29 initiated
    <debug> app: char val length 13
    <debug> app: Characteristic 0x2A24 initiated
    <debug> app: char val length 8
    <debug> app: Characteristic 0x2A25 initiated
    <debug> app: char val length 6
    <debug> app: Characteristic 0x2A26 initiated
    <debug> app: char val length 8
    <debug> app: Characteristic 0x2A27 initiated
    <debug> app: char val length 7
    <debug> app: Characteristic 0x2A28 initiated
    <debug> app: char val length 22
    <debug> app: Characteristic 0x2A2A initiated
    <debug> app: Service initiated
    <debug> app: char val length 1
    <debug> app: Failed to initialize characteristics. Error code: 0x04
    <error> app: Unable to create Battery Level characteristic. Error code 0x4
    <info> app: GHS Bt Sig Start at time 402!
    

    In another configuration it is the Reg-Cert-Data-List characteristic that fails in the same manner but the Battery Service and characteristic (generated after the DIS) is successful. The program still runs but  there s no battery level for the client to read.

    I am using the SES compiler to build the HEX because I have the size limited version of the Keil. But I can get an idea of the footprint from the Keil. So my Keil settings won't help much. THere are some advantages to using the Keil editor over the SES so I use both in development, but always build using SES.

  • Hello again,

    brianreinhold said:

    I do have logging enabled, and if I do not get a success I print the error code.

    The method giving the error is sd_ble_gatts_characteristic_add()

    Thank you for specifying. As mentioned, the APP_ERROR_CHECK would return a detailed error message whenever a non-NRF_SUCCESS error code is passed to it - but the information you provide about the error code and returning function should do the trick.

    brianreinhold said:
    I am using the SES compiler to build the HEX because I have the size limited version of the Keil. But I can get an idea of the footprint from the Keil. So my Keil settings won't help much. THere are some advantages to using the Keil editor over the SES so I use both in development, but always build using SES.

    What about your flash_placement.xml, or the SES project / build file? It will need to contain the Section Placement Macros (or section placements directly) that we can use to adjust the memory allocation.
    Usually the SoftDevice will provide debug information when there is not enough memory allocated for the configured characteristics and services, but I do not see any of that in your provided logs. How does your sdk_config.h look?

    Best regards,
    Karl

  • Karl,

    Yes, I recall that SoftDevice gave me now memory boundaries to set when I added support for MTU sizes greater than the default 23 bytes. But in that case the program basically died with the error message and the info I needed to adjust the memory. In this case the program runs fine (if you don't care about the characteristic that faulted).

    I can attach my sdk_config.h because I wouldn't know where to look in there to find the problem. It is huge and most of the items in it are a mystery to me as to what they do. 

    Is there a limit to the size of the service table? I was looking to attach the file but don't recall how to do that.

    Here is the memory layout

    start 0x20002B10

    size 0x3DDA0

    As I recall the start address had to move ur when I increased the maximum MTU size to make room for SoftDevice, but I don't recall what it was before.

  • Hello again, Brian

    Thank you for your patience with this - the national holiday here in Norway has now concluded, and so DevZone will return to regular operation.

    brianreinhold said:
    Yes, I recall that SoftDevice gave me now memory boundaries to set when I added support for MTU sizes greater than the default 23 bytes. But in that case the program basically died with the error message and the info I needed to adjust the memory. In this case the program runs fine (if you don't care about the characteristic that faulted).

    What did this error message say specifically? Was it the same NRF_ERROR_NO_MEM error as in the case with the characteristic?

    brianreinhold said:
    I can attach my sdk_config.h because I wouldn't know where to look in there to find the problem. It is huge and most of the items in it are a mystery to me as to what they do. 

    Sure thing, you can use the insert -> file option to share a file here on DevZone. Please let me know if you would like me to turn the ticket private, if the code requires it.
    Please do not hesitate to ask if there is anything you have questions about related to the sdk_config file.

    brianreinhold said:

    Is there a limit to the size of the service table? I was looking to attach the file but don't recall how to do that.

    Here is the memory layout

    start 0x20002B10

    size 0x3DDA0

    As I recall the start address had to move ur when I increased the maximum MTU size to make room for SoftDevice, but I don't recall what it was before.

    There is no such limit no, as long as the SoftDevice has adequate memory allocated to support the increased length. Did you change these as a result of the warning printed by the SoftDevice upon initialization? If so, could you share with me the exact warning text logged by the SoftDevice?

    Best regards,
    Karl

Related