Mesh Chat Model - Error Message = No free slots for new incoming segmented messages

[BlueMeshUK]

We are getting this message on our RELAY - via PuTTY.

"No free slots for new incoming segmented messages"

uart:~$ [01:00:53.683,380] <wrn> bt_mesh_transport: trans_seg: No free slots for new incoming segmented messages

then >>>

ASSERTION FAIL @ WEST_TOPDIR/zephyr/lib/os/ring_buffer.c:73

We are getting this error - using CHAT MODEL in MESH.  The RELAY gives us this same error message - we have increased the CONFIG_BT_MESH_ADV_BUF_COUNT value from 13 to 50.

We read here >>>  "No free slots" error while sending message  that adding a timing delay may help. 

We have not added a timing delay yet but lets say we use 0.1s between receiving and transmitting on to the proxy or the next Relay. Is this because of timing issues between the next available Tx slot being ready and the device being ready - or mistiming i should say.

How do we add a small delay?

We put this into our VS Code build - yes?

Please help if you can give us some information - many thanks.

We have nRF52840 BLE > nRF21540 DK as RELAY > nRF21540 DK as proxy.  

Thanks - Richard 

[TimD]

This is my prj.conf

2451.prj.conf

[TimD]

Hi Andreas, I few more questions:

Firstly I read somewhere that if the message is a max of 11bytes then the message doesn't need to be segmented. If thats the case why is the message "No free slots for new incoming segmented messages" appearing?

Also is there a way of getting rid of this warning "Ignoring old SeqAuth"?

Thanks

Tim

[TimD]

Hi Andreas,

The crash problem ASSERTION FAIL @ WEST_TOPDIR/zephyr/lib/os/ring_buffer.c:73 seems to be fixed by setting the messages to 11bytes max. I realised I didn't set the message buffer size on the relay to 11 (it was 60). After setting this the relay has been running for ~36 with 7 beacons advertising every 5 seconds. Our proxy crashed after 2 hours so I set the byte size to 11 
but didn't add
CONFIG_BT_MESH_RELAY_BUF_COUNT=256

I think the message "No free slots for new incoming segmented messages" has been misleading us to thinking this is the cause of the crash.

It would be good to understand why we are still seeing this message in the log and also the "Ignoring old SeqAuth" message as these messages are taking up most of the log file.

[AHaug]

Hi,

Apologies for the lack of response for the past two days, I've been out of office

Glad to hear that you were able to resolve the issue and thank you for sharing the fix! I must admit I also was mislead by the "no free slots for new incoming segmented messages" 

TimD said:

It would be good to understand why we are still seeing this message in the log and also the "Ignoring old SeqAuth" message as these messages are taking up most of the log file.

The log message is triggered in trans_seg() in zephyr/subsys/bluetooth/mesh/transport_legacy.c whenever the incoming messages sequence number is older than the current sequence number. Does the amount of these message change if you change the number of retransmissions you perform, or is it always the roughly the same amount?

Kind regards,
Andreas

[TimD]

Hi Andreas,

Ok so we've set the message size to 9bytes. This is a section of the log from the relay

<0x004C>: 030134
<0x004E>: 030336
<0x004A>: 030035
<0x004F>: 030735
message echo: Re:0000
<0x0050>: 030935
<0x004B>: 030535
<0x004D>: 030235
<0x004C>: 030134
<0x004E>: 030336
<0x004A>: 030035
<0x004F>: 030735
<0x0050>: 030935
<0x004B>: 030535
<0x004C>: 030134
<0x004E>: 030336
<0x004F>: 030735
<0x0050>: 030935
<0x004A>: 030035
<0x004C>: 030134
<0x004E>: 030336
<0x004F>: 030735
<0x0050>: 030935

i.e all warning message have disappeared. 

Somewhere in your documentation its says: For a vendor specific model, such as the chat model, messages with 9 or less bytes of payload should get sent in one packet (i.e. not segmented), which would go significantly faster due to two properties of segmented messages: