We are working on an application firmware that integrates multiple sensors and streams their data to the backend. In doing so, the usual free memory left during execution is about roughly 15KB (as we use FIFOs and FFTs).
However, whenever we go into the listeneing mode to configure the Wi-Fi, the Particle automatically resets itself as soon as we try to connect to it’s SSID for configuring the device. Even if we run a Wi-Fi configuring Web Page (this one), the page does not load. I tried to debug this and found that it was being caused due to lack of memory. Seems that SoftAP server itself takes about 25 - 35 KB memory to serve the page.
Is there a way in which we can lighten the SoftAP memory usage? Or is there a way in which we can clear the memory held by the application firmware instace so that SoftAP can have enough for itself? I was guessing there should be a function called (or maybe a callback in application context) where we can free the allocated memory by the application.
Any other deductions for the pages not loading are also welcome.
If you want to give back some of the dynamically allocated memory your firmware used, it’s up to your code. No system function would know what’s safe to free and what will be needed after returning to your code.
I am ready to give up all the memory (dynamically allocated, constants etc) used by the application, but is there a way (like a callback function in application context when moving to listening mode) that can be used to free the memory before going into listening mode from the application execution?
I’m not aware of a callback or event, but
WiFi.listening() in conjunction with
SYSTEM_THREAD(ENABLED) should be helpful and since your page handler will be called once a SoftAP page is requested, you may be able to do the freeing there before handing out the web page.
Also how do you expect Listening Mode to be entered?
If its via the SETUP button, you could use the button event
I’m not quite sure about the
setup_xxxx events, if these also apply to Listening Mode, but you could try
@ScruffR, can we reuse the button pushed event handler in application context? Besides, even if we use it, won’t it override the system firmware event for button handling (which potentially takes it to the desired listening mode).
It may, but there is no harm done since you can always call
WiFi.listen() to enter Listening Mode once you’re done freeing space.
That’s meant to be used in app context.
@ScruffR, got it. I will try doing that and move to listening mode after clearing any memory. Is there a system firmware call to automatically clear off any dynamically allocated memory (just curious).
Nope - apart from
OK. Even after system reset, any compile time memory is still already allocated as the application loads (before even application executes). We have some globally defined static arrays that take up much of the space. One of the ways to deal with is to allocate memory dynamically for the arrays, but is there a way (compiler directive or so) to build the firmware and allocate memory for global variables art runtime and not compile time?
I found some info about it via attribute ((section (".noinit"))) and #pragma arm section zidata = “non_init” http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3878.html but none of them seem to help.
Any update on how you solved this?
I am running into a problem that came out of further functional testing of a solution which integrates SoftAP for the WiFi setup. Ordinarily the setup process works just fine, however, if after running SoftAP once we delete the entered WAP credentials and repeat the process (to test the case that someone has incorrectly entered the first time and wishes to start afresh) the photon just hangs after calling WiFi.listen(). Using data collection from the application watchdog handler I can see that the free memory is 17440 bytes at this point whereas typically it is around 38500. I am guessing that SoftAP is not releasing memory after it exits from first use. Any fixes to this?
What system firmware version are you running? I had to revert from 0.7.0 because of continued crashing of softAP allocations with our app’s allocations. Downgrading to 0.6.3 and all has been operational since then using our softAP setup.
0.8.0-RC.10 and I cannot down grade to 0.6.3. Actually find 0.8.0 diagnostics extremely useful and need 0.7.0 features but without the disconnection problems.
The answer in this may be that the free memory is just on the edge the first time it is run and then the second time there has been a small bit of memory usage 100 bytes it becomes too low.