BLE Mesh Maximum ACCESS_MODEL_COUNT?

[Jeremy]

I have a modified version of the Mesh 'serial' example to which I have already added 5 custom models without any problems, but encountered a problem when attempting to integrate the "pb_remote_client" model to my project. Everything compiles and appears to function correctly, but in operation after receiving a multi-segment (3) message on one of my custom models, it appears to fail to send an ACK, then drop an "Application memory access" error crashing out.

<t:       6806>, main.c,  316, Bluetooth Mesh Serial Interface Application started!
<t:     185583>, transport.c,  931, Got segment 0
<t:     189125>, transport.c,  931, Got segment 1
<t:     192468>, transport.c,  931, Got segment 2
<t:     192473>, transport.c,  611, Sending ACK...
<t:     192488>, transport.c, 1045, Message decrypted
<t:     192508>, access.c,  253, RX: [aop: 0x00C0]
<t:     192513>, access.c,  276, RX: Msg: 1115011205000000000000FFFFFFFFFFFFFFFF04FF
<t:     192530>, access.c,  425, TX: [aop: 0x00C1] 
<t:     192535>, access.c,  426, TX: Msg: 00E000E0C0F3
<t:     192539>, main.c,  227, message_handle callback called
<t:     195822>, transport.c,  931, Got segment 0
<t:     199219>, transport.c,  931, Got segment 1
<t:     202803>, transport.c,  931, Got segment 2
<t:     202808>, transport.c,  611, Sending ACK...
<t:     289214>, transport.c,  931, Got segment 0
<t:     292533>, transport.c,  931, Got segment 1
<t:     296043>, transport.c,  931, Got segment 2
<t:     296048>, transport.c,  611, Sending ACK...
<t:     378580>, transport.c,  931, Got segment 0
<t:     382094>, transport.c,  931, Got segment 1
<t:     385631>, transport.c,  931, Got segment 2
<t:     385636>, transport.c,  611, Sending ACK...
<t:     563597>, app_error_weak.c,   99, Application memory access: 375680:1073741824

I rolled back to my previous working save before trying to add the "pb_remote_client" model, and the minimum change I need to make to my code to reproduce the error is simply increasing the ACCESS_MODEL_COUNT defined in 'nrf_mesh_config_app.h' from 7 (5+2) to 8. Recompiling with the increased ACCESS_MODEL_COUNT definition recreates this issue, even with no references to the new model.

From the comment before ACCESS_MODEL_COUNT, it sounds like this is a define that should be allowed to be too high, it just needs to be "equal at least to the number of models needed by the application plus two", but is is possible that this number must match and my issue is that I wasn't implementing "pb_remote_client" correctly?

I currently have all 7 models on a single element, and was trying to fit the new model there as well. Is there some maximum number of models per element I missed somewhere? All of my models are unique, so I'd like to stick to a single element for the addressing simplicity if possible.

Thanks,
Jeremy

Edit: This 3-segment message that causes the fault is also the very first message received by my custom model after provisioning. Provisioning still works without issue, but I'm not sure if the error is due to the message being multi-segmented, or potentially any message received by the custom model would trigger this behavior once ACCESS_MODEL_COUNT is incremented.

[Joakim Jakobsen]

Hi. 

Could you also share which version of the SDK and SD you are working with here?

____

You might have already looked at the documentation for the NRF_FAULT_ID_APP_MEMACC. 

Could you try to debug your application and find out which function is causing this? 

Similar ticket: 
Random NRF_FAULT_ID_APP_MEMACC errors 

Br, 
Joakim

[Jeremy]

Mesh SDK v5.0.0, nRF5 SDK v17.1.0, s132 v7.2.0, developing for an nRF52832

I'm not able to catch a breakpoint in the fault handler.

If I implement my own version of the weak app_error_fault_handler and add a breakpoint to it:

No breakpoint catches, but pausing the execution after the serial interface becomes non-responsive I see it is waiting at the default HardFault_Handler:

With breakpoints set at that line in ses_startup_nrf52.s, in my hander, and at 0xa60 as suggested in the other post, none of them catch and I'm only able to capture the above data by pausing the execution.

If I remove my app_error_fault_handler and fallback to the weak implementation, the behavior changes and I get the log message I was seeing yesterday, but the stack trace is less informative. Again no breakpoints catch and I'm only able to capture the information below by pausing execution after the serial interface becomes unresponsive.

Weird breakpoint handling aside, the "info" value being passed into the weak app_error_fault_handler is 0x40000000, so I think I may have a different issue then the ticket you referenced (where "info" = 0).

Any feedback on how to better handle breakpointing and debugging, or if you can provide any insight from the mess above would be appreciated. I'm using a 'Debug' build configuration with the following attributes (SES v5.44, Linux x64):

• gcc_debugging_level = "Level 3"
• gcc_entry_point = "Reset_Handler"
• gcc_omit_frame_pointer = "No"
• gcc_optimization_level = "None"

Thanks,
Jeremy

[Joakim Jakobsen]

Thanks.

Hard to know exactly without knowing where the error is coming from, but you might be able to solve it by allocating more memory for the application.

Is it possible that you could upload your complete nrf_mesh_config_app.h?

Also, the error print contains the pc value. You should be able to find it in the disasembly which would give you the file and line number.

Br,
Joakim

[Jeremy]

Currently the "RAM_START" define is set to 0x20002df0 which was the flash required by the soft device by the power up assert. Boosting this to 0x20003df0 had no impact on the issue. Is allocating more memory for the application more involved then just changing that flag?

nrf_mesh_config_app.h (removed auto-doc comments to make it a bit shorter):

#ifndef NRF_MESH_CONFIG_APP_H__
#define NRF_MESH_CONFIG_APP_H__

#include "chsh_mesh.h"
#include "app_config.h"

/** Device company identifier. */
#define DEVICE_COMPANY_ID (CHSH_COMPANY_ID)

/** Device product identifier. */
#define DEVICE_PRODUCT_ID (0x0000)

/** Device version identifier. */
#define DEVICE_VERSION_ID (0x0000)

/**
 * The default TTL value for the node.
 */
#define ACCESS_DEFAULT_TTL (4)

/**
 * The number of models in the application.
 *
 * @note To fit the configuration and health models, this value must equal at least
 * the number of models needed by the application plus two.
 */
#define ACCESS_MODEL_COUNT (/* Element 0:                                       */ \
                            1 + /* Config Server                                */ \
                            1 + /* Health Server                                */ \
                            1 + /* Rssi Scan Client                             */ \
                            1 + /* Message Client                               */ \
                            1 + /* Message Server                               */ \
                            1 + /* Network Health Client                        */ \
                            1   /* Network Health Server                        */ )

/**
 * The number of elements in the application.
 *
 * @warning If the application is to support _multiple instances_ of the _same_ model, these instances
 * cannot be in the same element and a separate element is needed for each new instance of the same model.
 */
#define ACCESS_ELEMENT_COUNT (CHSH_SERIAL_ACCESS_ELEMENT_COUNT)

/**
 * The number of allocated subscription lists for the application.
 *
 * @note This value must equal @ref ACCESS_MODEL_COUNT minus the number of
 * models operating on shared states.
 */
#define ACCESS_SUBSCRIPTION_LIST_COUNT (ACCESS_MODEL_COUNT)

/** Number of the allowed parallel transfers (size of the internal context pool). */
#define ACCESS_RELIABLE_TRANSFER_COUNT (ACCESS_MODEL_COUNT)

/** The number of instances of the health server model. */
#define HEALTH_SERVER_ELEMENT_COUNT (1)

/** Maximum number of subnetworks. */
#define DSM_SUBNET_MAX                                  (4)
/** Maximum number of applications. */
#define DSM_APP_MAX                                     (4)
/** Maximum number of device keys. */
#define DSM_DEVICE_MAX                                  (10)
/** Maximum number of virtual addresses. */
#define DSM_VIRTUAL_ADDR_MAX                            (8)
/** Maximum number of non-virtual addresses. */
#define DSM_NONVIRTUAL_ADDR_MAX                         (32)

/** Friend feature. */
#ifndef MESH_FEATURE_FRIEND_ENABLED
#define MESH_FEATURE_FRIEND_ENABLED 1
#endif

/** Number of friendships supported simultaneously. */
#ifndef MESH_FRIEND_FRIENDSHIP_COUNT
#define MESH_FRIEND_FRIENDSHIP_COUNT 5
#endif

/** Size of the Friend Subscription List (per friendship). */
#ifndef MESH_FRIEND_SUBLIST_SIZE
#define MESH_FRIEND_SUBLIST_SIZE 3
#endif

/** Size of the Friend Queue (per friendship).
 *
 * @note Set the queue size to a value higher than 32 to be able to receive at least one
 * of the longest segmented messages and one or more of the unsegmented messages. */
#ifndef MESH_FRIEND_QUEUE_SIZE
#define MESH_FRIEND_QUEUE_SIZE 128
#endif

#endif /* NRF_MESH_CONFIG_APP_H__ */

I'm not super familiar with the disassembly view, but I enabled "show labels" and "show source" and found the following at address 0x5BB80 (pc address from the fault handler).

Thanks for your help!

Jeremy

[Sigurd]

Hi,

Joakim is out of office. But looking at the stack trace, maybe increasing the value of PACKET_MGR_MEMORY_POOL_SIZE in nrf_mesh_config_core.h could help?