I’ve moved all my code out of STARTUP and am still encountering the same issue, tried an OTA update and that didn’t make a difference vs DFU.
I see mentions about SPI and should inform you I’m using both SPI buses on my P1 for I/O (SPI has an ePaper display ans SPI1 an SD card)
Attempting to flash the bootloader off github got me the following:
particle flash --usb p1-bootloader@1.5.0-rc.1+lto.bin
Error writing firmware: unknown module function 2, use --force to override
I ran an OTA flash of Tinker targeting 1.5.0-rc1 and got the following from an inspect
particle flash *** tinker --target 1.5.0-rc1
? Which type of device? P1
attempting to flash firmware to your device ***
Flash device OK: Update started
Flash success!
particle serial inspect
Platform: 8 - P1
Modules
Bootloader module #0 - version 400, main location, 16384 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1500, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 207
System module #2 - version 1500, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1500
Bootloader module #0 - version 400
User module #1 - version 3, main location, 131072 bytes max size
UUID: ***
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 6
@rickkas7, for some reason I thought the LIS3DH was using I2C. I guess this means a library update. The more reason to create the SPI_HAS_TRANSACTION#define in Particle.h and/or Arduino.h IMO.
It’s actually because I called SPI.begin() from the constructor, which shouldn’t be done. I’ll release new versions of the libraries to fix this, and also enable SPI transactions.
Over a year should have been plenty of time to add that single line of code to the device OS repo.
Excuse the sentiment, but I have lost count of issues I reported that never got a single official response.
Indifference is creeping in on my side for quite some time now.
I released version 0.3.2 of AssetTrackerRK that fixes the SOS+1 at startup with Device OS 1.5.0.
It contains LIS3DH 0.2.5 which actually has the fix; the problem was that SPI.begin() should not be called from a global object constructor. It also uses SPI transactions for compatibility with the Ethernet FeatherWing.
This is excellent news then - we have at least one root cause to the panic, ie SPI access
To close this case, it looks like I may need to update from SDFat 0.0.7 to 1.0.16 as per @ScruffR’s comments: DeviceOS 1.5.0-rc.1 - SoftAP using SDCARD - problem (assumption being that 0.0.7 may not be using SPI TRANSACTION or has SPI.begin() in the constructor???).
I note that I had tried quite some time ago to use the updated lib but came to grief for some reason.
As I had already modified Adafruit’s SSD1306 lib for SPI TRANSACTION usage, this should be sweet as it is.
@UMD Unfortunately, I was not able to figure out what causes the problem from the binaries you’ve provided. If you can find a way to provide a minimal application showcasing the problem, we can continue debugging.
@avtolstoy, happy to report that the SOS #1 PANIC with DeviceOS 1.5.0-rc.1 with compiling to the same target 1.5.0-rc.1 issue has been resolved in my app.
The issue was traced down (after a lot of work and #ifdefs !) to my NFC code (which out of interest uses I2C).
I had a call to pinMode(D7,input) in the constructor. I moved this to the begin() method which is called in setup().
I will report back on any other issues found under separate tickets.
Thanks for the assistance, as per usual, greatly appreciated!