• State Verified Answer
  • Replies 25 replies
  • Answers 1 answer
  • Subscribers 76 subscribers
  • Views 5708 views
  • Users 0 members are here
Attachments (9) Download All
Nordic Case Info
  • Case ID: 266231
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sensor_server with 5 Property IDs always failed in getting configuration (compositon_data_get) step using nRF Mesh (Android)

deno

Hi,

My development setup:

HW:  nRF52840 DK
SDK: nrf5_SDK_for_Mesh_v5.0.0_src + nRF5_SDK_17.0.2_d674dde + s140nrf52720
Provisioner: nRF Mesh Android app (Ver 3.1.0)

-----------------------------------------------------------------------------------

I modified sensor_server example (nrf5_SDK_for_Mesh_v5.0.0_src\examples\sensor\server) to support multiple Property IDs (2 to 5)

Below are the Property ID I used in the modified sensor_server app: 

#define SENSOR_MOTION_SENSED_PROPERTY_ID (0x0042)
#define SENSOR_PRESENCE_DETECT_PROPERTY_ID (0x004D)
#define SENSOR_PRESENT_AMBIENT_TEMPERATURE_PROPERTY_ID (0x004F)
#define SENSOR_PRESENT_AMBIENT_RELATIVE_HUMIDITY_PROPERTY_ID (0x0076)
#define SENSOR_PRESENT_AMBIENT_VOC_PROPERTY_ID (0x0078)

I have tried adding UP TO 4 Property IDs (and up to 4 descriptors), everything is working fine, i.e. able to get through provisioning and configuration successfully and work fine with sensor_client app to send the descriptor msg for all property ids and other test (per the sensor example)

  

Problem statement:
When the number of Property ID is increased to 5, during provisioning (using nRF Mesh Android app) process,  even though sensor_server is able to go through provisioning successfully (Note: On nRF Mesh mobile app: "<- Provisioning complete received" is shown) but it consistently failed/stopped at the "composition data get" step (Pls see nRF Mesh's  screenshot below)

I have repeatedly tried with 4 and 5 Property ID builds for several times and verified that the build with 4 Property ID is always OK in all aspects but for the build with 5 Property ID, the nRF Mesh always failed at the " -> Sending composition data get .." step. 

Some debugging info:
1. I have put in some log message in handle_composition_data_get in handle_composition_data_get() (in config_server.c) and noticed that the function runs ok all the way till the end (i.e. app_evt_send(&evt). 

2. The handle_config_default_ttl_get() is not invoked for the case of 5 Property ID

This is unclear to me the issue lies with nRF52840 firmware or with the nRF Mesh mobile app.

Pls advise what needs to be done to make the sensor_server_model capable of supporting 5 Property IDs (for 5 sensors).

Another side issue:
When the sensor_server model supports only 3 sensors (3 Property IDs and 3 descriptors), I am able to click "Get Sensor" on nRF Mesh app to get the 3 sensors info showing up (under Sensor Information section). However, when testing with sensor_server with 4 sensors (4 Property ID and 4 descriptors). Upon clicking the "Get Sensor" on nRF Mesh, the nRF Mesh app will either has no response or exit from Sensor Server model screen. 

 

 

Parents
  • 0

    Hi,

    Could you provide me with your firmware if possible? And a step-by-step procedure on how I can try reproduce this on my side.

  • 0 in reply to Mttrinh

    Thank you for the code and the step-by-step procedure, I will try reproducing the issue and come back to you.

  • 0 in reply to deno

    Hi,

    Thank you for the information and logs. We need some more logs to try narrow down the issue. Could you apply this new patch with more logs and collect the data one more time? output2.patch

    deno said:
    I will try to collect Android log tomorrow.

    That would be great :) 

  • 0 in reply to Mttrinh

    Hi,

    Here are the RTT log and adb log taken after output2.patch applied:

    Fullscreen 5_property_issue_w_patch2_trial2_26Mar2021.log Download 
    # SEGGER J-Link RTT Viewer V6.88a Terminal Log File
# Compiled: 15:12:58 on Nov 18 2020
# Logging started @ 26 Mar 2021 21:41:21
00> <t:          0>, main.c, 1201, ----- WPSN Sensor Server (Relay Node) Demo -----
00> <t:      12894>, main.c, 1013, Initializing and adding models
00> <t:      12900>, main.c, 1020, App Sensor Setup Server Model Handle - no errs: 3
00> <t:      12904>, main.c, 1029, App Battery Server Model Handle - no errs: 4
00> <t:      17781>, mesh_app_utils.c,   66, Device UUID (raw): 54AF46540F2E415CB0BB4C7D1AC12488
00> <t:      17784>, mesh_app_utils.c,   67, Device UUID : 54AF4654-0F2E-415C-B0BB-4C7D1AC12488
00> <t:      17802>, main.c, 1308, 
00>     ---------------------------------------------------
00>      Button/RTT 1) To publish sensor data of temperature sensor.
00>      Button/RTT 2) To publish present battery state value.
00>      Button/RTT 3) Unused.
00>      Button/RTT 4) Clear all the states to reset the node.
00>     ---------------------------------------------------
00> <t:    1490092>, mesh_gatt.c,  241, conn_index_alloc: 0
00> <t:    1507346>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1582250>, mesh_gatt.c,  582, New MTU: 66
00> <t:    1583242>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1652577>, main.c,  657, Device identification started
00> <t:    1652585>, mesh_gatt.c,  168, HVN data: 03010100010001000000000000
00> <t:    1652590>, mesh_gatt.c,  219, status: 0 len: 13 usable-mtu:66 sar_type: 0 
00> <t:    1652595>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1664369>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1782336>, main.c,  666, Device identification stopped
00> <t:    1794145>, mesh_gatt.c,  168, HVN data: 03037DEAA25A7300316EDDE1C7FDEFCA4B0CDB7748884D1C97FC6470BC2D00AD5BA4CD2DF5880D5167CA73DB9D469D5A1A3D5E846024DDE22ADD0E189E9582A3DD0D
00> <t:    1794153>, mesh_gatt.c,  219, status: 0 len: 66 usable-mtu:66 sar_type: 0 
00> <t:    1798933>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1817728>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1817751>, mesh_gatt.c,  168, HVN data: 030545FE659528638235717B8D5C5543F60E
00> <t:    1817756>, mesh_gatt.c,  219, status: 0 len: 18 usable-mtu:66 sar_type: 0 
00> <t:    1817762>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1829524>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1829540>, mesh_gatt.c,  168, HVN data: 03067958D0A74C5F363F66A88336ADC1F4AD
00> <t:    1829545>, mesh_gatt.c,  219, status: 0 len: 18 usable-mtu:66 sar_type: 0 
00> <t:    1829564>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1841319>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1841348>, mesh_gatt.c,  168, HVN data: 0308
00> <t:    1841352>, mesh_gatt.c,  219, status: 0 len: 2 usable-mtu:66 sar_type: 0 
00> <t:    1841399>, config_server.c, 3205, config_server_bind
00> <t:    1841405>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1853108>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1882609>, mesh_gatt.c,  256, conn_index_free: 0
00> <t:    1883494>, main.c,  672, Successfully provisioned
00> <t:    1883499>, main.c,  732, Node Address: 0x0002 
00> <t:    1883504>, main.c,  938, Battery voltage (mV): 318, Battery level: 0%
00> <t:    1990603>, mesh_gatt.c,  241, conn_index_alloc: 0
00> <t:    1990606>, proxy.c,  633, Connected
00> <t:    2008600>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    2083504>, mesh_gatt.c,  582, New MTU: 66
00> <t:    2084488>, proxy.c,  671, TX ready
00> <t:    2084498>, mesh_gatt.c,  168, HVN data: 01010069D9DFAC36B7F33200000000BD788471B6ED5649
00> <t:    2084503>, mesh_gatt.c,  219, status: 0 len: 23 usable-mtu:66 sar_type: 0 
00> <t:    2084509>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    2084513>, proxy.c,  684, TX complete
00> <t:    2084515>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    2100745>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    2159749>, proxy.c,  676, RX
00> <t:    2159755>, proxy.c,  607, RX GATT PDU type 0x0, len 21
00> <t:    2159770>, access.c,  253, RX: [aop: 0x8008]
00> <t:    2159772>, access.c,  276, RX: Msg: FF
00> <t:    2159775>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x0000  alloc? 1  addr_match? 1  key_bound? 1  opcode? 1
00> <t:    2159781>, config_server.c,  898, composition_data_get:: 590000000000280007000000050000000200001101110C10
00> <t:    2159785>, config_server.c,  205, access_model_reply status: 4
00> <t:    2159788>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x0002  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    2159793>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x1100  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    2159798>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x1101  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    2159803>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x100C  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    2866542>, main.c,  938, Battery voltage (mV): 312, Battery level: 0%
00> <t:    3849582>, main.c,  938, Battery voltage (mV): 306, Battery level: 0%
00> <t:    4832622>, main.c,  938, Battery voltage (mV): 312, Battery level: 0%
00> <t:    5815662>, main.c,  938, Battery voltage (mV): 312, Battery level: 0%

# Logging stopped @ 26 Mar 2021 21:44:27

    adb_logcat_w_patch2_trial2.log

  • 0 in reply to deno

    It seems like the access layer couldn't allocate the packet using mesh_mem_alloc as it returned NRF_ERROR_NO_MEM.

    I suggest you to increase PACKET_MGR_MEMORY_POOL_SIZE.

  • 0 in reply to Mttrinh

    Ok, I will try to increase it from 4096 to 5120 and see if it helps to solve. Thanks

  • 0 in reply to Mttrinh

    Hi,

    Question: The warning regarding the max size of packet manager memory pool does not seem to reflect the current values used. Pls see text highlighted in red below.

    Can you advise what value of PACKET_MGR_MEMORY_POOL_SIZE should I use?

    In mesh\core\api\nrf_mesh_config_core.h: 

    /**
    * Size of the packet manager memory pool in bytes.
    * @warning The value of the memory pool cannot currently exceed the value of
    * PACKET_MGR_PACKET_MAXLEN, due to the current design of the memory manager.
    */
    #ifndef PACKET_MGR_MEMORY_POOL_SIZE
    #define PACKET_MGR_MEMORY_POOL_SIZE 4096
    #endif

    In mesh\core\include\packet_mgr.h

    /** Maximum length of the packets that can be allocated. */
    #define PACKET_MGR_PACKET_MAXLEN    (NRF_MESH_SEG_PAYLOAD_SIZE_MAX)

    In mesh\core\api\nrf_mesh_defines.h

    /** Maximum possible segmented payload size (octets). */
    #define NRF_MESH_SEG_PAYLOAD_SIZE_MAX (380)

Reply
  • 0 in reply to Mttrinh

    Hi,

    Question: The warning regarding the max size of packet manager memory pool does not seem to reflect the current values used. Pls see text highlighted in red below.

    Can you advise what value of PACKET_MGR_MEMORY_POOL_SIZE should I use?

    In mesh\core\api\nrf_mesh_config_core.h: 

    /**
    * Size of the packet manager memory pool in bytes.
    * @warning The value of the memory pool cannot currently exceed the value of
    * PACKET_MGR_PACKET_MAXLEN, due to the current design of the memory manager.
    */
    #ifndef PACKET_MGR_MEMORY_POOL_SIZE
    #define PACKET_MGR_MEMORY_POOL_SIZE 4096
    #endif

    In mesh\core\include\packet_mgr.h

    /** Maximum length of the packets that can be allocated. */
    #define PACKET_MGR_PACKET_MAXLEN    (NRF_MESH_SEG_PAYLOAD_SIZE_MAX)

    In mesh\core\api\nrf_mesh_defines.h

    /** Maximum possible segmented payload size (octets). */
    #define NRF_MESH_SEG_PAYLOAD_SIZE_MAX (380)

Children
  • 0 in reply to deno

    It seems to be a legacy warning and can be ignored. From our developer:

    I think I realised why the number of properties breaks configuration:

    The memory pool size is common for the whole stack. app_sensor_utils.c uses it to allocate cadence for each property id that is defined for the sensor (see app_sensor_utils.c::sensor_initialize and app_sensor_utils.c::cadence_new). Usually, the default value in PACKET_MGR_MEMORY_POOL_SIZE is enough and this problem won't occur. I think, analysing the memory size allocated by app_sensor_utils.c::cadence_new can help them to understand how big PACKET_MGR_MEMORY_POOL_SIZE should be.

  • 0 in reply to Mttrinh

    Hi Mttrinh,

    I tried with increasing PACKET_MGR_MEMORY_POOL_SIZE by 512 bytes to 4608 (in view of the cadence bytes needed ranges from 184 to 212 bytes) but the problem is still there. Pls see attached log that was taken with build with PACKET_MGR_MEMORY_POOL_SIZE of 4608 bytes.

    Fullscreen 5_property_memory_pool_4608.log Download 
    # SEGGER J-Link RTT Viewer V6.88a Terminal Log File
# Compiled: 15:12:58 on Nov 18 2020
# Logging started @ 27 Mar 2021 08:30:24
00> <t:          0>, main.c, 1228, ----- WPSN Sensor Server (Relay Node) Demo -----
00> <t:      12390>, main.c, 1091, Sensor Identity: 0x33
00> <t:      12937>, main.c, 1028, Initializing and adding models
00> <t:      12940>, app_sensor_utils.c,  609, *** cadence bytes: 212 bytes.
00> <t:      12944>, app_sensor_utils.c,  609, *** cadence bytes: 184 bytes.
00> <t:      12947>, app_sensor_utils.c,  609, *** cadence bytes: 184 bytes.
00> <t:      12950>, app_sensor_utils.c,  609, *** cadence bytes: 188 bytes.
00> <t:      12954>, app_sensor_utils.c,  609, *** cadence bytes: 188 bytes.
00> <t:      12958>, main.c, 1035, App Sensor Setup Server Model Handle - no errs: 3
00> <t:      12962>, main.c, 1044, App Battery Server Model Handle - no errs: 4
00> <t:      17765>, mesh_app_utils.c,   66, Device UUID (raw): 826DE3E08C914076BD26DCE15E0984B1
00> <t:      17768>, mesh_app_utils.c,   67, Device UUID : 826DE3E0-8C91-4076-BD26-DCE15E0984B1
00> <t:      17783>, main.c, 1335, 
00>     ---------------------------------------------------
00>      Button/RTT 1) To publish sensor data of temperature sensor.
00>      Button/RTT 2) To publish present battery state value.
00>      Button/RTT 3) Unused.
00>      Button/RTT 4) Clear all the states to reset the node.
00>     ---------------------------------------------------
00> <t:     763005>, mesh_gatt.c,  241, conn_index_alloc: 0
00> <t:     784267>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:     859335>, mesh_gatt.c,  582, New MTU: 66
00> <t:     860079>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:     923764>, main.c,  656, Device identification started
00> <t:     923772>, mesh_gatt.c,  168, HVN data: 03010100010001000000000000
00> <t:     923776>, mesh_gatt.c,  219, status: 0 len: 13 usable-mtu:66 sar_type: 0 
00> <t:     923781>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:     935556>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1024033>, main.c,  665, Device identification stopped
00> <t:    1029943>, mesh_gatt.c,  168, HVN data: 030320F6D21D158A5087F8AACF9A08D70007EBF8A614BCE1FC6EEC9ADB88ED849489C41C6CD948561CC89432CABC78F8096B163AA7F8221EA3CFA1775154937BB77F
00> <t:    1029950>, mesh_gatt.c,  219, status: 0 len: 66 usable-mtu:66 sar_type: 0 
00> <t:    1034729>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1047628>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1047651>, mesh_gatt.c,  168, HVN data: 030589D426C6D15B72A0B4EA1A9A29A224AE
00> <t:    1047656>, mesh_gatt.c,  219, status: 0 len: 18 usable-mtu:66 sar_type: 0 
00> <t:    1047661>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1059424>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1059439>, mesh_gatt.c,  168, HVN data: 0306797F07105D5B275750AB4386E5400E6A
00> <t:    1059444>, mesh_gatt.c,  219, status: 0 len: 18 usable-mtu:66 sar_type: 0 
00> <t:    1059463>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1071219>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1071248>, mesh_gatt.c,  168, HVN data: 0308
00> <t:    1071252>, mesh_gatt.c,  219, status: 0 len: 2 usable-mtu:66 sar_type: 0 
00> <t:    1071298>, config_server.c, 3205, config_server_bind
00> <t:    1071304>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1083008>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1112509>, mesh_gatt.c,  256, conn_index_free: 0
00> <t:    1113399>, main.c,  671, Successfully provisioned
00> <t:    1113404>, main.c,  731, Node Address: 0x0002 
00> <t:    1113411>, main.c,  937, Battery voltage (mV): 348, Battery level: 0%
00> <t:    1113437>, main.c,  974, LIS3DH X,Y,Z: 333333333333
00> <t:    1208051>, mesh_gatt.c,  241, conn_index_alloc: 0
00> <t:    1208053>, proxy.c,  633, Connected
00> <t:    1227196>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1302059>, mesh_gatt.c,  582, New MTU: 66
00> <t:    1303043>, proxy.c,  671, TX ready
00> <t:    1303053>, mesh_gatt.c,  168, HVN data: 0101005DAA5C7F71415CC800000000F16F51282A272B07
00> <t:    1303058>, mesh_gatt.c,  219, status: 0 len: 23 usable-mtu:66 sar_type: 0 
00> <t:    1303063>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1303067>, proxy.c,  684, TX complete
00> <t:    1303069>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1319300>, mesh_gatt.c,  405, Couldn't pop packet from buffer
00> <t:    1378304>, proxy.c,  676, RX
00> <t:    1378310>, proxy.c,  607, RX GATT PDU type 0x0, len 21
00> <t:    1378325>, access.c,  253, RX: [aop: 0x8008]
00> <t:    1378327>, access.c,  276, RX: Msg: FF
00> <t:    1378329>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x0000  alloc? 1  addr_match? 1  key_bound? 1  opcode? 1
00> <t:    1378335>, config_server.c,  898, composition_data_get:: 590000000000280007000000050000000200001101110C10
00> <t:    1378339>, config_server.c,  205, access_model_reply status: 4
00> <t:    1378342>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x0002  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    1378347>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x1100  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    1378351>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x1101  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    1378356>, access.c, 1087, cmp_id: 0xFFFF mdl_id: 0x100C  alloc? 1  addr_match? 1  key_bound? 0  opcode? 0
00> <t:    2096447>, main.c,  937, Battery voltage (mV): 336, Battery level: 0%
00> <t:    3079487>, main.c,  937, Battery voltage (mV): 336, Battery level: 0%
00> <t:    4062527>, main.c,  937, Battery voltage (mV): 336, Battery level: 0%

# Logging stopped @ 27 Mar 2021  8:33: 6

    Pls help to investigate again and advise what else needs to be modified. Thank you.

  • +1 in reply to deno

    Hi,

    My apologies, it seems like the problem was elsewhere.

    The problem is that for SES projects we set heap size to 1024 bytes: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/CMake/SES/SESGenerator.py#L165

    Set arm_linker_heap_size to 2048 in .emProject file and that will solve it.

  • 0 in reply to Mttrinh

    Hi Mttrinh,

    Increasing the heap size to 2048 does help to resolve the issue. Thanks for your great help and support! 

Related
Terms of service