Can't get p2 to enter listening mode from normal mode after flashing

I'm having very similar issues to this recent thread.
I'll haven't yet tried to try a clean install of nodejs and nvm as was mentioned in that thread, but I fear that I'll just end up in the same place. Right now I'm also getting the "Not allowed" returned from device.js when running cli commands while the device is in normal mode, when it worked fine the other day.

C:\Users\tommy>particle usb listen -v
Getting device information...
Sending a command to the device...
Not allowed
RequestError: Not allowed
    at klass.sendProtobufRequest (C:\Users\tommy\AppData\Local\particle\node_modules\particle-cli\node_modules\particle-usb\src\device.js:778:10)
    at async C:\Users\tommy\AppData\Local\particle\node_modules\particle-cli\node_modules\particle-usb\src\device.js:272:4
    at async Promise.all (index 0)
    at async CLI.runCommand (C:\Users\tommy\AppData\Local\particle\node_modules\particle-cli\src\app\cli.js:148:4)
    at async CLI.run (C:\Users\tommy\AppData\Local\particle\node_modules\particle-cli\src\app\cli.js:175:11)

It only became this way after flashing this example for the current Device OS, 5.3.2.
Now, the only way I can enter listening mode is by first going to safe-mode first, even after reflashing everything with the browser utility and using tinker.

C:\Users\tommy>particle serial inspect
Platform: 32 - Photon 2 / P2
Modules
  Bootloader module #0 - version 2102, main location, 65536 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      Bootloader module #2 - version 5
  Bootloader module #1 - version 2, main location, 8192 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  Bootloader module #2 - version 5, main location, 303104 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 5302, main location, 2097152 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      Bootloader module #0 - version 2102
  User module #1 - version 6, main location, 2097152 bytes max size
    UUID: A7322EE10C7C27209917E0613C5C23CD5E4B184EBF27665E01BB4003173B141A
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 5302

Also, I cannot get into listening mode with the SETUP button, unless the p2 is already in safe mode. If I try to hold SETUP for 3 seconds and release from standard mode, I get rapid cyan blinks, one red blink, one green blink, then back to breathing cyan. I similarly get rapid cyan blinks when calling particle usb listen from the cli (this also momentarily disconnects the cloud session if running my firmware, but not tinker).

UPDATE 1
I just now used the web device doctor and didn't realize it reverted to Device OS 5.1.0... but that does seem to fix the issue. I'll try to stay on 5.1.0 for now but I hope this post is still helpful to someone who's having issues with 5.3.2? I'll try some other versions and see what I find. Not sure if reverting to an older version would make this "solved" but it keeps me moving forward for now.

UPDATE 2
So after I got everything working on with the browser device doctor I was then able to use device-os-flash to get it back to 5.3.2 and could then enter listening mode normally. I tried flashing that BLE wifi setup example again, and reproduced the same issue and have an output identical to the other support thread.

C:\Users\tommy>device-os-flash 5.3.2 --all-devices -v
Initializing module cache
Found cached module binaries
Initializing flash interface
Enumerating local devices
Detected devices:
1. 0a10aced202194944a022780
Flashing target devices
Target devices:
1. 0a10aced202194944a022780 (P2)
[Device 1] Skipping p2-prebootloader-mbr@5.3.2.bin. It's required to be encrypted
[Device 1] Preparing device for flashing
[Device 1] Entering DFU mode
[Device 1] Flashing p2-system-part1@5.3.2.bin
[Device 1] $ dfu-util -d 0x2b04:0xd020 -S 0a10aced202194944a022780 -a 0 -s 0x08060000 -D C:/Users/tommy/.particle/device-os-flash/binaries/5.3.2/p2/p2-system-part1@5.3.2.bin
[Device 1] Flashed in 24.4s
[Device 1] Flashing p2-tinker@5.3.2.bin
[Device 1] $ dfu-util -d 0x2b04:0xd020 -S 0a10aced202194944a022780 -a 0 -s 0x085f4000 -D C:/Users/tommy/.particle/device-os-flash/binaries/5.3.2/p2/p2-tinker@5.3.2.bin
[Device 1] Flashed in 1.2s
[Device 1] Resetting device
[Device 1] Using control requests to flash remaining modules
[Device 1] Preparing device for flashing
[Device 1] Entering listening mode
[Device 1] Not allowed
[Device 1] Flashing p2-prebootloader-part1@5.3.2.bin
[Device 1] Flashed in 3.7s
[Device 1] Preparing device for flashing
[Device 1] Entering listening mode
[Device 1] Not allowed
[Device 1] Flashing p2-bootloader@5.3.2.bin
[Device 1] Flashed in 10.9s
[Device 1] Flashed successfully
Done

No matter what Device OS I use with device-os-flash, the p2 will not enter listening mode unless I go back to the doctor and flash from there.

ALSO the example I'm using literally says STARTUP(System.enableFeature(FEATURE_DISABLE_LISTENING_MODE)); and I am illiterate. Though it is kinda odd that it persists between reflashing anything through device-os-flash. Should I just explicitly enable all features that are default in my user firmware, just in case I flash something that disabled them previously? If I went with this wifi setup route and disabled listening mode, then I'd never be able to do things that require the device to be in listening mode, such as identify the p2 or use serial monitor.

what we have seen: it will only enter listen mode if you flash (once) code with the following line:

STARTUP(System.disableFeature(FEATURE_DISABLE_LISTENING_MODE));

hope this helps!

1 Like

Exactly, so my question becomes should we explicitly set the default features in our user firmware since device-os-flash won't set them for us? Or should I maybe include a step that starts by flashing the device doctor user-part so that default features are reset? I just want to be able to have 100% confidence that a device will have the same behavior after flashing it in production.

when flashing in the factory it will need to work with the p2 as it comes from the particle factory.

we use "device-os-flash" to flash our application (replace the "tinker" bin with your own application and it will flash that).

the sequence we have now is (for a "fresh" p2 connected to usb):

  • particle usb listen
  • particle identify
  • device-os-flash --all-devices 5.3.2

good luck!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.