Hi,
I think you have deadlock situation or wrongly used interface in driver at_cmd.
The master branch is using functionality using function at_cmd_set_notification_handler
This sets callback function to be called whenever the recieve thread gets the response.
This callbeck is called using default work queu:
k_work_init(&item->work, callback_worker);
k_work_submit(&item->work);
This could be fine if you dont use semaphore to be blocked in the caller work.
More specific in driver for modem link lte_link_control -> connect from same work queue it causes deadlock, becasue the connect function will block on semaphore and wait for it to be realease which cannot be done via the work submit in the at_cmd drive because the whole workqueue is block by the semaphore inside the lte_link_control driver.
This bug does not appear if the lte_link_control is called from the main function because the main function is propably called from non default work queue or it is invoked in separet thread.
I think this should be solved by either calling the callback function directly from the thread already running inside the at_cmd driver.
Replace:
k_work_init(&item->work, callback_worker);
k_work_submit(&item->work);
With:
callback_worker(&item->work);
This is easy and will work.
Or create its own work_queue.
Or some how make an example which will tell us how to call the lte_link_control from task not the main function.
Thank you
