DeviceOS 1.5.0-rc.1 - SoftAP using SDCARD - problem

[UMD]

@avtolstoy unfortunately need to inform you that I picked up another breaking change from DeviceOS 1.4.4 to 1.5.0-rc.1.

The issue is that due to code size constraints, I have had to shift the SoftAP “website’s” html, css and Javascript from hardcoded C++ string constants to text files on an SDCARD (which is the ideal way to do it).

This regime worked fine under DeviceOS 1.4.4, but is broken when running DeviceOS 1.5.0-rc.1 (noting that the binary had to be compiled for target DeviceOS 1.4.4 as per Updating from DeviceOS 1.4.4 to 1.5.0-rc.1 -> SOS Panic 1).

The outcome is that in SoftAP mode, the device does not respond to pings and hence it a browser cannot connect to the web service on port 80.

This could be due to:

• the SPI issue you mentioned, and/or
• increased memory usage of the updated DeviceOS??? SoftAP is sensitive to this.

[ScruffR]

Have you got your SPI calles wrapped in SPI transactions?

BTW, even when you have disclosed your used platform in some other thread(s) it's always good to mention that again in any new thread (or use the platform tags).

Could you also add a link or a quote to the "SPI issue" you are refering to for other readers to get the context?
I'll do that here for now

@avtolstoy

I have reproduced your issue and it’s related to our changes to have better thread-safety for SPI between system and application on Gen 3, however some changes affected Gen 2 devices as well. The key problem on Gen 2 devices is due to the undefined order in which the global C++ constructors are called ( STARTUP() macro creates an object in the global namespace with a constructor containing the code in the macro), the application-specific mutex for SPI class is not yet initialized at the point pinMode() is called in your STARTUP() macro and it needs to be for safety-checks on a pin configuration to be successfully made.

We’ll fix this in 1.5.0-rc.2. As a temporary workaround, please move any code that interacts with GPIO out of STARTUP() macro and perhaps into setup() .

[UMD]

@ScruffR, good points!

Platform = P1.

Am using SDFat v0.0.7 which is included as an external lib using the Particle Dev environment. Don’t have the source to it, so can’t comment on the SPI Transaction.

But have added SPI Transactions to the Adafruit SSD1306 lib as I have the source. Here is the change log for the record:

2019-08-07 HR
- Adafruit_SSD1306:: fixed Display vs SDCARD workaround by defining
  SPI_HAS_TRANSACTION and calling SPI.beginTransaction() and
	SPI.endTransaction() before and after SPI transfers respectively.
  ResetInterface() dummied out if SPI_HAS_TRANSACTION defined
  as is not required anymore

Fingers crossed that DeviceOS 1.5.0-rc.2 brings relief…

[ScruffR]

@UMD

Am using SDFat v0.0.7

There is a much more recent version 1.0.16 available (with sources)

And this long standing issue may prevent the proper use of transactions despite the library supporting it
https://github.com/particle-iot/device-os/issues/1668