Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Client stops after 6:25 hours...

Hi there!

I'm currently facing an issue where the client will stop transmitting messages after six hours and twenty-five minutes. This is the case after 255 messages have been sent. These messages are part of a custom model that's based on the Simple OnOff Model. The hardware that's showing the behaviour varies from a nRF52840 DK to a nRF52840 Feather and custom built PCB. So I don't think hardware is part of the problem. The application is built with the GNU Arm Embedded Toolchain, is written in C++ and uses both the nRF5 SDK and Mesh SDK running on FreeRTOS.

I'm sure it's the client since when I reset one device, the other device starts receiving the messages again. The server on the device that hasn't been reset is thus able to receive the messages. However, I don't think the server is able to acknowledge them; the messages are received multiple (~5) times. Hence, the probleem seems to be with transmitting messages.

I first thought it was the transaction id of the messages (uint8_t) that overflows after 255 messages have been sent. So I wrote a function that makes sure the tid is set back to 0 when 255 is reached. This, however, didn't change the behaviour.

I'm afraid the problem goes a little deeper. I thought it'd be a good idea to ask around here since I'm absoutely clueless...

Kind regards,

A (very) confused Jochem

  • Hi,

    Setting the field manually to 0 when it is about to overflow should have the same effect of letting it overflow, so both working the same is as expected.

    I have not found anything in the simple on/off model that indicates that an overflowing tid field there should cause any issues. I did not find any check of that field on the server side, similar to the model_tid_validate() function used by the generic on/off model and others. The field is on the application level, and so the implementation for checking it is up to the application. I would start by checking how the application handles the field, in both ends.

    Regards,
    Terje

  • Hi Tesc, 

    Sorry for the delay. Thanks for letting this know. I made a reasoning mistake regarding the tid's. The application doesn't do anything with the tid's. I assumed they were neccesary for the model to operate.

    Okay, so, I've got some debugging to do ;). Thanks anyway!

    Kind regards,

    Jochem

  • Hi,

    Thank you for the update. You can of course use the time that you need. Feel free to continue the discussion if you find anything in your debugging, or have new related questions.

    Regards,
    Terje

Related