10ms sounds like a very tight time frame. I'll investigate the reason for the deadlock, seems to me like a problem with the network stack rather.

If you want to investigate yourself: The ps shell command can help you find deadlocks. If it's a double mutex-lock (the table printed by ps will show bl mutex for the thread in question) I usually put some wrapper macros into core/include/mutex.h to find out where the double lock happens:

/**
 * @brief Locks a mutex, blocking.
 *
 * @param[in] mutex Mutex object to lock. Has to be initialized first. Must not be NULL.
 */
static inline void __mutex_lock(mutex_t *mutex)
{
    _mutex_lock(mutex, 1);
}

/**
 * @brief Unlocks the mutex.
 *
 * @param[in] mutex Mutex object to unlock, must not be NULL.
 */
void __mutex_unlock(mutex_t *mutex);

#include <stdio.h>

#define mutex_lock(m) printf("%s:%d: lock %p\n", __FILE__, __LINE__, (void *)&m); __mutex_lock(m)
#define mutex_unlock(m) printf("%s:%d: unlock %p\n", __FILE__, __LINE__, (void *)&m); __mutex_unlock(m)

(of course mutex_unlock() to __mutex_unlock() needs also be renamed in core/mutex.c)

You then can identify a double lock with a lock to a pointer without an unlock in-between.

As a workaround for now: Are you bound to the 10ms time frame? If not I'd advice to try to go for something more relaxed like 500-1000 ms. With those I made good experiences in the past. I even have demo were I did a notification for a CoAP GET OBSERVE (similar mechanism to MQTT-SN Publish QoS 0, just different protocol) every ~100ms over a radio which ran for several hours.

Side-question: which QoS are you using? As you did not mention connection or registration I guess QoS -1 with a predefined topic ID or short topic?

asymcute die because of dead lock? #11811

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions