I am running version 0.7.0 of the Device OS and have enabled system threading. I am using the built-in SoftAP functionality and have not created any custom pages. I have read in other posts that SoftAP requires at least 20k of RAM to correctly save credentials. Inspecting RAM before entering listen mode I have 35864 bytes of RAM available. After entering listen mode that drops to 15304 bytes and when I issue the scan-ap request it drops further to 15088 bytes. Finally when I call configure-ap I get a response code of -16640 and the credentials are not saved.
I think you don’t have enough free memory. I have spent a lot of time debugging this exact issue… I think if you start the SoftAP process with less than 40k free you will get inconsistent results. For us there were not any critical features or bug fixes in 0.7 so we reverted to 0.6.3 which freed up like 5k. We’re now running with about 42k free and haven’t had any issues with SoftAP.
Hey @andrewa thanks for the input. I dug into this deeply last night in debug mode and stepped through the source. In the monolithic build everything works properly. I’ve spent the morning walking through the source code and I may have a lead to follow that could be a bug with non-null-terminated strings in the softap code. It looks promising and could explain a lot of the behavior I’ve seen the last couple of days with SoftAP issues. I’ll post an update here after I have some more data.
Super long day short. I was finally able to get things back on track doing a particle keys doctor. Since I’m not using the Particle cloud I’m not sure why this ended up being the solution but my best guess is that running the doctor command clear/re-arranged some memory on the P1 that made things happy again. I hate that that’s the answer and not something more concrete but that’s the best I’ve got right now.
More follow up on this that might help others. It turns out that all of my devices exhibiting this behavior didn’t have valid public keys. The public-key call from the SoftAP page would return 256 bytes of FF. To fix this issue it’s not necessary to run particle keys doctor if you aren’t using the Particle Cloud as is my case. All I needed to do was generate new keys with particle keys new and then load the private key onto the device with particle keys load [der file]. The particle keys doctor process does these things but will also want to register the public key with the Particle Cloud which is an unnecessary extra step, especially if you are doing this as part of a manufacturing line process.