# Listening mode on the Photon cannot work reliably in current implementation

**URL:** <https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789>\
**Category:** Libraries\
**Tags:** photon\
**Created:** [April 21, 2020, 9:04am UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789 "2020-04-21T09:04:30Z")\
**Posts on this page:** 15\
**Page:** 2

<div class="post-metadata">

**Author:** ![Elco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/elco/32/3234_2.png) [@Elco](https://community.particle.io/u/Elco)\
**Post date:** [April 27, 2020, 10:51pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/21 "2020-04-27T22:51:47Z")

</div>

I think the biggest issue here is not that SoftAP uses a lot or RAM, but that listening mode not only starts SoftAP, but also a http server with 10 pages.  
You can probably make your app work by using the simpler TCP protocol over SoftAP. The memory hungry http pages are by no means a requirement for SoftAP to be functional.

The reply I got from particle on GitHub was that SoftAP is part of WICED, so it is not something they can do something about directly, so they are flagging it as a feature request.  
This is wrong for 2 reasons:

- A huge chunk of the memory is allocated by Particle code, not by WICED, and not all of it is essential. It could easily be made optional.
- If a dependency is in a _closed source_ third party dependency, that doesn’t make it a feature request. It is just a bug in a dependency. It is still _your_ responsibility to do something about this bug. We cannot even access the code. I would be glad to do so otherwise.

---

<div class="post-metadata">

**Author:** ![no1089](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/no1089/32/24051_2.png) [@no1089](https://community.particle.io/u/no1089)\
**Post date:** [April 28, 2020, 8:15pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/22 "2020-04-28T20:15:25Z")

</div>

SoftAP won’t be arriving on Gen3, at all. (I’ve confirmed this internally)

---

<div class="post-metadata">

**Author:** ![Mjones](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mjones/32/21658_2.png) [@Mjones](https://community.particle.io/u/Mjones)\
**Post date:** [April 29, 2020, 2:46am UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/23 "2020-04-29T02:46:49Z")

</div>

Sad to hear. That takes our product out of Particle the Particle lineup.

---

<div class="post-metadata">

**Author:** ![dan.s](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dan.s/32/24623_2.png) [@dan.s](https://community.particle.io/u/dan.s)\
**Post date:** [May 4, 2020, 11:45am UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/24 "2020-05-04T11:45:34Z")

</div>

100% agree with this. We currently have 481 photons online (in a 1652 fleet) all on v0.6.2 because when we attempted upgrading to v0.7.0 when it came out, we were getting strange problems when changing WiFi details (via softAP). Our app requires the HTTP server, and works fine out of the box, but as soon as our firmware is installed and the customer tries to change the WiFi credentials in exactly the same way as they did originally, it would fail (and we would get a very frustrated customer).  
The major bugbear was that we had no idea why it would do this - everything in our code worked fine in v0.6.2, and almost entirely worked fine in v0.7.0. It was only after a few days of debugging did we figure this issue out - the time was spent checking our own code and assuming Particle side was fine and tested (this version was not a pre-release)!

We have made do with v0.6.2 for the time being, but would really like to gain some advantages of the updated versions. To get round this we have decided to add expandable memory to our board for all future hardware.

I have just come across this thread and would like to give my support for this issue.

My question would be; what happened between v.0.6.2 and v0.7.0 to precipitate this need for memory?

---

<div class="post-metadata">

**Author:** ![Elco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/elco/32/3234_2.png) [@Elco](https://community.particle.io/u/Elco)\
**Post date:** [May 4, 2020, 8:08pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/25 "2020-05-04T20:08:28Z")

</div>

I know they introduced support for customizing the HTTP pages, but don’t know when this happend.  
If you use the default pages, it should be possible to use a pointer to program memory, which uses no ram at all. But the current implementation first copies all the pages to an array in RAM memory, which I think can be avoided.

Even if the users wants custom pages, I think most of the page content can still be defined as static const or constexpr and never be copied to RAM.

---

<div class="post-metadata">

**Author:** ![dan.s](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dan.s/32/24623_2.png) [@dan.s](https://community.particle.io/u/dan.s)\
**Post date:** [May 5, 2020, 5:20pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/26 "2020-05-05T17:20:58Z")

</div>

Yes a pointer would be ideal, maybe have the ability to stream the data from any source too e.g. external memory.

I think the problems started around v0.7.0 when Particle started supporting WPA/WPA2 Enterprise credentials, which prompted the creation of the `WiFiCredentials` class.

---

<div class="post-metadata">

**Author:** ![dan.s](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dan.s/32/24623_2.png) [@dan.s](https://community.particle.io/u/dan.s)\
**Post date:** [June 13, 2020, 3:34pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/27 "2020-06-13T15:34:51Z")

</div>

To further a workaround, I have a simpler, alternative solution to @UMD (which was making a setup2 to allocate heap memory only if not in listening mode).

Let me know if you see any “new” downsides to this one (I’m hoping to roll this out to new firmware in our fleet);  
When listening mode detected, restart the device and go into listening mode before any initialisations.  
Sample code looks like this:

```auto
STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY));
retained uint8_t listenMode = 0;
void setup() {
  if(listenMode){
    listenMode=0;
    WiFi.listen();
  }
  // initialisations and heap memory allocation
}
void loop () {
  if(WiFi.listening()){
    listenMode=1;
    System.reset();
  }
  // do useful stuff here
}

```

---

<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:** [June 14, 2020, 8:21am UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/28 "2020-06-14T08:21:43Z")

</div>

@dan.s, brilliant solution, clever!

Had to review: [https://docs.particle.io/reference/device-os/firmware/photon/#enabling-backup-ram-sram-](https://docs.particle.io/reference/device-os/firmware/photon/#enabling-backup-ram-sram-) to fully understand that the following line:

> retained uint8\_t listenMode = 0;

only initialises listenMode on a **power cycle** , ie NOT on a soft reset.

@Elco, is this a solution for you?

I will test myself and report back.

---

<div class="post-metadata">

**Author:** ![dan.s](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dan.s/32/24623_2.png) [@dan.s](https://community.particle.io/u/dan.s)\
**Post date:** [June 14, 2020, 4:14pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/29 "2020-06-14T16:14:05Z")

</div>

Thank you @UMD ! Yes that’s right, it persists on soft reset but we’ve also found it persists on power cycle too with a large enough input capacitor.  
We use retained memory a lot because our devices need to work offline too and they are useful for resuming the previous state without having to connect online (we also use manual mode and system threads) there is a very good description written by @rickkas7 here: [Retained Memory Tips](https://community.particle.io/t/retained-memory-tips/38137)

A caveat though if using system threading, you must remember to add `waitUntil(WiFi.ready)` after entering listening mode to prevent it ruining our plans to avoid the subsequent heap memory allocation!

Let me know if your tests work and if you see any possible drawbacks.

---

<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:** [June 14, 2020, 11:24pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/30 "2020-06-14T23:24:44Z")

</div>

Oh oh… Am using system threading… To me adding waitUntil(WiFi.ready) does not make sense because it is a Catch 22 - the fact that you are in listening mode is typically because you don’t have a WiFi connection or am I interpreting this requirement incorrectly?

---

<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:** [June 15, 2020, 9:40am UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/31 "2020-06-15T09:40:15Z")

</div>

@dan.s, unfortunately I was unsuccessful with my testing, endless reset loops…

I note that I did not add waitUntil(WiFi.ready).

Am pretty sure that my issue with your work around is SYSTEM\_THREAD(ENABLED).

Keep up the good work.

---

<div class="post-metadata">

**Author:** ![dan.s](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dan.s/32/24623_2.png) [@dan.s](https://community.particle.io/u/dan.s)\
**Post date:** [June 15, 2020, 10:16am UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/32 "2020-06-15T10:16:12Z")

</div>

If using system threading, you will need to `waitUntil(WiFi.ready`) before moving on, otherwise the other thread will be free to run the loop and then reset the device before you’ve had chance to do anything!

In our user flowchart, we generally have:

1. Out of the box -\> factory firmware with enough memory to program WiFi credentials normally.
2. Once connected online, our firmware is downloaded and memory is at a premium. If WiFi stays the same, there is no need to softAP so no problem.
3. However, if the user wants to change WiFi, this is where the trick comes in. The device reboots, enters listening mode before memory taken up, user inputs WiFi credentials and the `WiFi.ready` becomes true, therefore moving past the `waitUntil` statement and into the main code - taking up lots of memory once again.

---

<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:** [June 15, 2020, 1:00pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/33 "2020-06-15T13:00:15Z")

</div>

Aha, now understand the need for WiFi.ready()!

This explains the issue I was having.

Will need to change the position of the _if (listenMode)_ block however as access is needed to the SDCARD for my implementation of SoftAP (I store the Javascript there to save code space).

Will report back on Take II…

---

<div class="post-metadata">

**Author:** ![dan.s](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dan.s/32/24623_2.png) [@dan.s](https://community.particle.io/u/dan.s)\
**Post date:** [June 15, 2020, 1:22pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/34 "2020-06-15T13:22:44Z")

</div>

Yes it should still work - we also initialise the SD library (used for logging) beforehand.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/3/2/3291e3c9351789fe8620ae5bcec8d3fec67ff221.png) [@system](https://community.particle.io/u/system)\
**Post date:** [August 14, 2020, 1:22pm UTC](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789/35 "2020-08-14T13:22:47Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

[Previous page](https://community.particle.io/t/listening-mode-on-the-photon-cannot-work-reliably-in-current-implementation/55789.md?page=1)