Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

802.15.4 MAC mlme_reset_req assertion error at sys_memory_manager.c 286, 304 and 308

Hi,

I am performing several "mlme_reset_req()" on a nrf52840 during runtime without problem, for the most part.

However sometimes the radio stack will stop after a "mlme_reset_req()" and give assertion error at sys_memory_manager.c 286, 304 and 308, in sequence.

This occurs at seemingly random occasions, causing our application to stop.

Do you have any idea what could be the cause?

BR

Linus

  • Hello Linus,

    Can you say a bit more about what is running on the raspberry pi and what you programmed on the nRF52840?

    Best regards,

    Edvin

  • Hi,

    The device we are developing is a proprietary usb radio unit with different purposes. 

    One part of the application needs to send "mlme_poll_req()" to a hub which will respond with just an ack or an ack and data.

    These polls need to be sent within a specified interval. 

    Sometimes the poll request will not get a callback within this interval.

    (Especially when the hub only answers with an ack and no data, then the radio stack seems to freeze up)

    The application has therefore a watchdog, and if the watchdog barks a "mlme_reset_req()" is sent.

    This works most of the time, however, we have noticed that sometimes the application will freeze after a "mlme_reset_req()".

    We have incorporated our own queue, ensuring only one mlme or mcps request at a time.

    void sendPollRequest( void )
    {
        m_mlme_poll_req.coord_address.short_address = uhfpGetCoordShortAddr();
        m_mlme_poll_req.coord_pan_id = uhfpGetPanId();
        m_mlme_poll_req.coord_addr_mode = MAC_ADDR_SHORT;
    
        NRF_LOG_INFO("Send poll request");
    
        /*  Send the poll request to MLME. */
        mlme_poll_req((mlme_poll_req_t*)&m_mlme_poll_req, (mlme_poll_conf_cb_t)mlme_poll_confirm_cb);
        start_confirm_watchdog();
    }

    Sending poll request

    static void confirm_watchdog_cb()
    {
    	/* NRF_LOG_INFO("Confirm Watchdog Barks %s:%l", __FILE__, __LINE__); */
        NRF_LOG_INFO("Watchdog, reset mlme");
    	m_mlme_reset_req.set_default_pib = false;
    	mlme_reset_req(&m_mlme_reset_req, mlme_reset_watchdog_cb);
    }

    Reset request, this is where the application hangs

  • Oh, you are using the "wireless_uart" example from the SDK\examples\802.15.4\ folder?

    Unfortunately, this is an old external library, and we don't have anyone currently working here that are familiar with this library.

    sys_memory_manager.c is part of the 802_15_4_keil.lib file. So why it doesn't respond, or why it fails in the first place, I don't know.

    What you can do is to try to enable the actual watchdog that is present on the nRF, instead of a software based watchdog. 

    Best regards,

    Edvin

  • Thank you for your response!

    Yes I am using the functions from that example anyways.

    The native watchdog seems interesting, how to you go about to enable that?

    Can it be configured through the 802.15.4 library?

    The reason we are using a software-based watchdog is because we could not get the mlme_poll_request to timeout and return "MAC NO DATA" or similar.

    Best Regards,

    Linus 

  • linusRyttermalm said:
    Can it be configured through the 802.15.4 library?

    No, and I don't see why that would be needed.. As mentioned, we don't have anyone who knows the internals of this library. 

    To see how to enable the physical WDT, please see the example found in SDK\examples\peripheral\wdt.

    Best regards,

    Edvin

Related