Sleepy end device causing missed report of variable change

Greetings, i'm developing a custom sleepy end device whose role is to detect whether a certain event is occurring, this triggers the update (EDIT: via interrupt handler) of a custom cluster boolean attribute that is then reported to the coordinator, once the event stops being detected, the boolean attribute is then reset by means of a Zephyr timer.

I have noticed that, with the sleepy end device behavior configured, sometimes the device fails to report the change from "false" to "true", but then reports correctly the change back to false when the timer expires.

A check with a packet sniffer further confirmed the fact that the packet is simply not being sent.

How can i solve this issue?
Thanks in advance

EDIT: addendum
After setting up the project to log to RTT and checking more with a DK running the Shell sample as coordinator, i see the following:
-the sending of the report packet seems delayed by around 2-4 seconds (tested by counting the time between a led turning off, signaling the update of the attribute to false and the reception of the report)
-the RTT does not seem to grab all logs in a timely manner, sometimes losing or receiving LOG_INF in a delayed manner, i do not know if this is related

Parents
  • Hi  
    I would reply directly to your comment but apparently the site has decided to not show me, no matter what, the button to reply to your message.

    The SDK version is 1.9.1 as it still works with SES. As for a minimal project where such thing is reproduced... We'll try but we are in a bit of a time crunch unfortunately due to other projects. Could upload the current project or its source if you prefer but it's configured for a custom board.

  • Hi,

    If it is not too much work to change it to using a DK then you can upload it and I will test. Let me know if you want me to make the ticket private before you upload the project.

    Best regards,

    Marte

  • After convening with my colleagues there appears to be no need to make the ticket private. 
    I'm uploading a tar archive containing a version of the project that works in the dk.
    Do note the following:
    1) The modifications from the original source are all in main.c, a text search for the __TEST__ string will highlight the modifications done
    2) The trigger handler has been slaved to the buttons_changed function, we hope it will still work in interrupt context
    3) As much as we would have liked to test this version of the firmware to see if the issue repeats even with such modifications, we find ourselves unable to as SES has managed to brick the nrf52840dk board we were planning on using as a coordinator, thing for which we'll open a new ticket, and we're leery of risking more as of right now.
    archive.tgz

Reply
  • After convening with my colleagues there appears to be no need to make the ticket private. 
    I'm uploading a tar archive containing a version of the project that works in the dk.
    Do note the following:
    1) The modifications from the original source are all in main.c, a text search for the __TEST__ string will highlight the modifications done
    2) The trigger handler has been slaved to the buttons_changed function, we hope it will still work in interrupt context
    3) As much as we would have liked to test this version of the firmware to see if the issue repeats even with such modifications, we find ourselves unable to as SES has managed to brick the nrf52840dk board we were planning on using as a coordinator, thing for which we'll open a new ticket, and we're leery of risking more as of right now.
    archive.tgz

Children
No Data
Related