This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Group address message crashes all nodes?!

Hi there!

Me again... I'm having issues with networks that consist of more than two nodes. When my network consists of three nodes and one node sends a message to another, the node that wasn't addressed, crashes. The network consists of one nRF52840 DK, one nRF52840 Feather and one nRF52832 DK. They are all running FreeRTOS and are built with ARMGCC on Windows 10.

The same happens when a message is sent to all nodes (0xFFFF); they both crash. I see a pattern, but find it hard to point to a cause. It looks like the node crashes when it receives a message that isn't addressed to exactly and only him. Underneath a snippet of output in the terminal from the server; the logging just stops and FreeRTOS freezes.

<info> app: RX: [aop: 0x00C1]

<info> app: RX: Msg
<info> app: Led is now turned off.
<info> app: TX: [aop: 0x00C4]

<info> app: TX: Msg

Underneath a snippet of the terminal from the client side.

<info> app: TX: [aop: 0x00C1] 

<info> app: TX: Msg
<info> app: Set "off" has been called.
<info> app: RX: [aop: 0x00C1]

<info> app: RX: Msg
<info> app: Led is now turned off.
<info> app: TX: [aop: 0x00C4] 

<info> app: TX: Msg
<info> app: RX: [aop: 0x00C4]

<info> app: RX: Msg
<info> app: Server acknowledged.
<info> app: TX: [aop: 0x00C1] 

<info> app: TX: Msg
<info> app: RX: [aop: 0x00C1]

<info> app: RX: Msg
<info> app: Led is now turned off.
<info> app: TX: [aop: 0x00C4]

<info> app: TX: Msg
<info> app: RX: [aop: 0x00C4]

<info> app: RX: Msg
<info> app: Server acknowledged.

When the client sends a message to specifically a unicast address, the server receives and handles it like below.

<info> app: RX: [aop: 0x00C1]

<info> app: RX: Msg
<info> app: Led is now turned off.
<info> app: TX: [aop: 0x00C4]

<info> app: TX: Msg
<info> app: RX: [aop: 0x00C1]

<info> app: RX: Msg
<info> app: Led is now turned off.
<info> app: TX: [aop: 0x00C4]

<info> app: TX: Msg

Furthermore, this problem also occurs with messages from proxy nodes; getting the ttl value or composition data will result in a crash for all other nodes. I have absolutely no idea as to what might cause the described behaviour. Has anyone got an idea of what might cause the problem? The weird thing is that it worked for a good while until i reset all nodes and provisioned them again.

Thanks in advance and kind regards,

Jochem

  • Hi,

    Could you give some more details on what you mean by your node "crashing"? Is it a hardfault? app_error_handler? or other resets?

    Also, can you provide which SDK versions you are using?

  • Hi Mttrinh,

    I don't know really. It just stops... Nothing is printed in the terminal. I'll look into it right now though! 

    As for your second question; I'm using V4.2.0 from the SDK for Mesh and V17.0.2 from the nRF5 SDK.

    Kind regards,

    Jochem

  • Hi Mttrinh,

    After enabling the configASSERT in FreeRTOS, I managed to produce output in the terminal. This is what's printed in the terminal of the server with unicast address 0x0002 when the client transmits to 0xFFFF.

    <info> app: RX: [aop: 0x00C1]
    
    <info> app: RX: Msg
    <info> app: Led is now turned on.
    <info> app: TX: [aop: 0x00C4]
    
    <info> app: TX: Msg
    <error> app: ASSERTION FAILED at :0

    And this is what the debugger shows.

    Program
     received signal SIGTRAP, Trace/breakpoint trap.
    0x00052aa4 in app_error_fault_handler (id=id@entry=16386, pc=324690, info=info@entry=536902224) at C:/Users/kraan/Downloads/clean/nRF5_SDK_17.0.2_d674dde/components/libraries/util/app_error_weak.c:100
    100	    NRF_BREAKPOINT_COND;
    

    Hence, it appears to be a weak app error. A quick look in the Q&A shows 'ASSERTION FAILED at :0' is most likely caused by calling 'NRF_MESH_ASSERT(false)'. Is that correct? It isn't anywhere in code written by me. 

    Kind regards,

    Jochem

  • Hi Mttrinh,

    Now I can't even get the composition data or ttl after adding a newly provisioned node... I'm absolutely clueless... The same errors occur.

    Changing to SoftDevice 'S140_nrf52_7.0.1' doesn't change anything. Maybe it's important to note that the provisioning through the app does never work and I always have to do it manually which is, impossible now.

    Kind regards,

    Jochem

  • Hi Mttrinh,

    I'm glad to let you know I can provision the nodes again; reverted a couple of commits... The problem as described in the opening post is still the same though.

    Kind regards,

    Jochem

Related