# WiFi reconnection issue - what does this trace mean?

**URL:** <https://community.particle.io/t/wifi-reconnection-issue-what-does-this-trace-mean/55703>\
**Category:** Firmware\
**Created:** [April 16, 2020, 12:22am UTC](https://community.particle.io/t/wifi-reconnection-issue-what-does-this-trace-mean/55703 "2020-04-16T00:22:40Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![UMD](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/umd/32/5850_2.png) [@UMD](https://community.particle.io/u/UMD)\
**Post date:** [April 22, 2020, 12:09am UTC](https://community.particle.io/t/wifi-reconnection-issue-what-does-this-trace-mean/55703/8 "2020-04-22T00:09:07Z")

</div>

@Elco, now that is very interesting indeed! Makes sense.

Have you raised a _support ticket_ for your finding as per @ScruffR comments here: [WiFi.ready() == FALSE but WiFi is connected - #3 by ScruffR](https://community.particle.io/t/wifi-ready-false-but-wifi-is-connected/55788/3) ?

@avtolstoy, any comment on @Elco's statement:

> I think the interaction with SPI is that the SPI class uses a recursive os mutex. If there is no free memory, allocation fails, the mutex cannot get a lock and a deadlock occurs.

Re accessing the **HAL functions directly** , how is this done? I did not think that this could be done from the application. If so, great!

---

_[View the full topic](https://community.particle.io/t/wifi-reconnection-issue-what-does-this-trace-mean/55703)._