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.