Photon won't come out of SOS+1 blink mode no matter what I do

From what appears to be a bad OTA firmware push, one of my photons won’t come out of sos mode. On reset/power up, LED goes white, then immediately to SOS with a single flash afterwords. No other colors in between.

Recovery (magenta) mode also doesn’t work. briefly goes magenta, then white, back to SOS+1

I can get it to DFU mode.

I’ve tried all the obvious stuff:
-particle update
-particle flash --usb ~/Downloads/system-part1-0.5.3-photon.bin && particle flash --usb ~/Downloads/system-part2-0.5.3-photon.bin
-particle flash --factory --usb tinker

nothing works. always reboots into sos mode. Any ideas?

1 Like

It is (almost) three years later and I am running into what seems to be exactly the same with my P1.
(Surprised I do not see any responses though).
Same signature: White flash followed by the SOS+1.
When i put the board to DFU mode it enumerates in the USB (Win USB Device) with believable descriptors

idVendor: 0x2B04
idProduct: 0xD008
bcdDevice: 0x0250
iManufacturer: 0x01
0x0409: “Particle”
iProduct: 0x02
0x0409: “P1 DFU Mode”
0x0409: “P1 DFU Mode”

I tried (almost) the same steps as karlg100:

C:\Users\current_user>particle update

Your device is ready for a system update.
This process should take about 30 seconds. Here it goes!
! System firmware update successfully completed!
Your device should now restart automatically.
===> SOS+1 again
C:\Users\current_user>particle flash --factory --usb tinker
Flash success!

C:\Users\current_user>particle flash --usb p1-system-part1@1.4.0.bin
Flash success!

C:\Users\current_user>particle flash --usb p1-system-part2@1.4.0.bin
Flash success!

The (yelowish-green) flashing in the DFU mode gets non-periodic during flashing so there is an indication that something is happening.
But the outcome is the same “SOS+1” after reset.

Any suggestions? I can dig-out some of my JTAG adapters (though I don’t have active experience with ST but still have some ST eval-boards with JTAG I may break-off (unless my trusty TI adapters won’t work with @@@? tools).
The P1 is soldered on a target. Are there any specific pins which I should verify? Power (and USB pins :-)) are happy. Is the SPI FLASH internal to the module connected to the same SPI bus which is pinned-out on pins #21, #22, #23 and #24? (Looking for possible contention). The design is using I2C. Should I look there?

I am stuck. Thanks!

Have you also flashed the actual application module via particle flash --usb tinker -v?
particle flash --factory --usb tinker only flashes a copy to the factory reset location but does not replace the current application.

What does Safe Mode do?
What does particle serial inspect give you?

Thanks - I feel less deserted when someone listens to the “SOS” :slight_smile:
Few more data points:
In most cases there is no serial port recognized by the host (W10) definitely not in the SOS+1 mode and not in the DFU either. So particle serial inspect
doesn’t help in my case. I tried particle device doctor
(abbreviated:)
C:\Users\current_user>particle device doctor -v
Updating system firmware on the device…dfu-util 0.8
DFU mode device DFU version 011a
DfuSe interface name: "Internal Flash "
Downloading to address = 0x080c0000, size = 16008
Downloading to address = 0x000006d9, size = 1
Downloading to address = 0x08020000, size = 237608
Downloading to address = 0x08060000, size = 257964
Downloadng syste[=========================] 100% 257964 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
! System firmware update successfully completed!

Your device should now restart automatically.
Flashing the Device Doctor app
==> resets to SOS+1
Put the device in DFU mode
Downloading to address = 0x080a0000, size = 6888
==> Now BREATHING WHITE
Configure IP address
==> skip
Clear all data in EEPROM storage
==> Yes Cleared EEPROM data
Clearing and setting up Wi-Fi settings
==> Yes … goes to SOS+1 flashing and by itself back to breathing white
? Select Continue when ready Continue
Cleared Wi-Fi credentials
Entering listen mode
? Should I scan for nearby Wi-Fi networks? Yes
The Doctor didn’t complete successfully. Unable to scan for Wi-Fi networks. Do you have permission to do that on this system?
VError: Unable to scan for Wi-Fi networks. Do you have permission to do that on this system?
at wifiScan (C:\Users\current_user\AppData\Local\particle\node_modules\particle-cli\dist\cmd\serial.js:487:25)
at C:\Users\current_user\AppData\Local\particle\node_modules\particle-cli\node_modules\node-wifiscanner2\lib\netsh.js:60:13
at ChildProcess.exithandler (child_process.js:288:5)
at emitTwo (events.js:126:13)
at ChildProcess.emit (events.js:214:7)
at maybeClose (internal/child_process.js:915:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
Please visit our community forums for help with this error:
https://community.particle.io/

C:\Users\current_user>particle serial inspect
Could not get inspect device: Serial timed out

Attempt to get to Setup mode gets me to the SOS+1 preceded by single purple flash. Then after a while Particle gets back to the white breathing.

Device is recognized as com port under the OS:
particle serial inspect
Could not get inspect device: Serial timed out

particle flash --usb tinker -v
dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Opening DFU capable USB device…
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x080a0000, size = 5324
Download [=========================] 100% 5324 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Flash success!

==> Brings the device back to “SOS+1”

Thanks for any further pointers!
Martin

Have you tried Listening Mode - this would be the mode particle serial inspect has to be used with.

Thanks - and sorry for the latency: Wasn’t able to get to my machine until now:
I am not sure I can (know how) to get to the listening mode:
a) After reset the device is in error state (SOS+1). Doesn’t enumerate on USB at all. Cannot get it to listen mode by pressing the SETUP button. Only when I hold the SETUP for a while (10 seconds) the P1 enters DFU mode.
b) In DFU mode it enumerates as WinUSB device. Attempt to put in “listening mode”:
particle usb start-listening
The device should not be in DFU mode
Is there anything I am missing?

This is a P1 on a released PCBA which is manufactured in quantity and known to work. Here the P1 might have been DOA or there may be another HW issue. Removing P1 seems to be almost impossible so I am trying to troubleshoot down to possible assembly issue or bad component creating bus contention(?). (Hence my previous design whether the SPI Flash on the module shares the same SPI I/F as is pinned-out. (Does the “particle flash …” actually receive confirmation that the data has been written and verified? (Says “Flash success!”).
It seems to me that the module responds enough to the level that one should be able to pin-point the issue. I am clearly lacking the depth of knowledge.
The PCBA has a stamp from the CM that it has been XRAY’d). Therefore I wouldn’t suspect shorts on the LGA.
Inspection under microscope suggests possible poor soldering job on pin #13. However, this is GND and unless it actually is dedicated signal as opposed to redundant GND connection I would consider that this likely isn’t the issue. What do you think?
which external connections should be on my list for this kind of behavior?
Thanks!

In your previous post of three days ago I couldn’t see what happended when you tried Safe Mode.
When you try Safe Mode you can also try to engage Listening Mode from there (aka Safe Listening Mode).

Was that clarified in my previous post? The only code what seems to be doing what expected(?) seems to be the DFU. Loading tinker app seems to result in SOS and no safe (listening) mode from there - at leas to my knowledge. Are there please any more steps I can perform (such as loading some debugging apps with perhaps limited function just to check certain portion of the design? Device doctor seems to load some binary which does result in white breathing pattern and device enumerating as serial port. However, the script itself times-out after loading the doctor app.
The Doctor didn’t complete successfully. Could not find serial device. Ensure the Device Doctor app was flashed
Error: Could not find serial device. Ensure the Device Doctor app was flashed
at _enterDfuMode.then.then.then.device (C:\Users\current_user\AppData\Local\particle\node_modules\particle-cli\dist\cmd\doctor.js:191:15)
at
at process._tickCallback (internal/process/next_tick.js:189:7)

Looks like it sometimes takes Windows a second longer to enumerate the new USB device and the script times-out before it does or sometimes it needs physical disconnect and reconnect to USB (reset doesn’t sometimes do it - may be HW design on the module - how the module pulls-up DP or DM line?).
Thanks - M.

You could flash this

Or you could just come up with any minimal test code that focuses on your specific needs
e.g.

SYSTEM_MODE(MANUAL)                          // prevent the system from connecting automatically

void setup() {
  pinMode(D7, OUTPUT);
}
void loop() {
  if (!digitalRead(BTN)) WiFi.listen();      // get into Listening Mode when taping SETUP
  digitalWrite(D7, (millis() >> 3) & 0x88);  // some D7 LED blink pattern
}

You can build that for any device OS version less or equal to the version you currently got on your device.

*dfu-util -d 2b04:d008 -a 0 -s 0x8020000:leave -D combined-p1.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device…
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08020000, size = 534460
Download [=========================] 100% 534460 bytes
Download done.
File downloaded successfully

C:\Users\current_user>particle serial monitor
Opening serial monitor for com port: “COM19”*
… nothing seems to happen as the P1 after 2 or three seconds goes from White_Breathe to red SOS.
Disconnect and reconnect from usb and fire “particle serial monitor” within the short window between enumeration and red SOS:
particle serial monitor
Opening serial monitor for com port: “COM19”
Serial monitor opened successfully:

… and nothing happens (red SOS) until I hit reset
Serial connection closed.
Note that SETUP doesn’t seem to do anything.
I also scoped the 3.3V line and didn’t see any dip. As little as I know about P1 I suspect that this suggestion I found on the forum could have been related to the BCM chip overloading the supply once being enabled (due to it’s structural failure(?)).
MFG - Martin

Looks like I am climbing a steep slope:
I tried to build (compile) the test you kindly suggested. But I (probably) cannot compile since I cannot claim that P1 as my device because I cannot get it on the network first. Catch 22? Perhaps I need to get first a functional device as a reference.

True for Web IDE, but you don’t need a claimed device to use CLI or Workbench to compile the code and flash the device.

Thanks for the pointer. Compiled your tiny source as well as an empty project:
SYSTEM_MODE(MANUAL) // prevent the system from connecting automatically
void setup() {}
void loop() {}

Flashing:
particle flash --factory --usb p1_firmware_1570071399602.bin -v as an example
When I reset the system afterwards there is a short white flash followed by the “SOS+1” I am getting used to watch last two weeks :wink:
No response to SETUP (as probably expected) and nothing enumerated on USB - again probably without surprise.
Let me re-state my objective: This is a proven design with an obvious HW failure. I am trying to partition:

  • Is this a failure of the P1 or
  • Failure of components interfacing with P1
  • poor soldering of the P1 LGA? (Pin #13 (GND) visually suspicious; all the rest looking OK and the PCBA was subject to X-RAY inspection.
    I can count my loss but I invested too much time and feel like I should be able to get better understanding since the thing responds to some level.
    Recht vielen Dank - M.

Why would you flash to the --factory backup location? This will not replace your current application but only the factory backup which won’t be exectued ever.

You want to flash that into the application area via
particle flash --usb <yourFirmware.bin> -v

Thanks for the explanation. I actually already tried either/or without much luck.
particle flash --usb <yourFirmware.bin> -v
results is a brief white flash followed by red SOS. “–factory” option let is stay in the DFU mode.
The only situation when I am not getting SOS after reset (except for DFU mode) is
particle device doctor -v
After entering DFU for the second time it attempts to flash it’s app and complains that serial port wasn’t found.
Downloading to address = 0x080a0000, size = 6888
Download [=========================] 100% 6888 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
The Doctor didn’t complete successfully. Could not find serial device. Ensure the Device Doctor app was flashed
Error: Could not find serial device. Ensure the Device Doctor app was flashed
at _enterDfuMode.then.then.then.device (C:\Users\current_user\AppData\Local\particle\node_modules\particle-cli\dist\cmd\doctor.js:191:15)
at
at process._tickCallback (internal/process/next_tick.js:189:7)

It may just time out too early. I can see the serial device afterwards via
particle serial list
Found 1 device connected via serial:
COM16 - P1

However this is only “serial” command I am successful with.
particle serial inspect
Could not get inspect device: Serial timed out
particle serial identify
Serial timed out