I’ve started transition a project I’ve been working on off of Photon breadboards and onto custom boards with a P1.
After a lot of trial and error, I’ve determined that I’m unable to DFU flash firmware to my custom boards, but cloud flashing works just fine. It doesn’t matter if I locally compile or download the binary, and it doesn’t matter which application I try flashing (I’ve tried both my code and Tinker and in both cases DFU doesn’t work and cloud flashing does)
Now I’m not 100% sure what’s going wrong as the LEDs we put on the boards have an opaque lenses and I’m not sure what color they’re supposed to be at any time. I believe that the devices are stuck trying to connect to the WiFi/cloud, but this seems odd as my application doesn’t utilize any cloud functions and works fine when not connected. So I really don’t know what’s wrong other than something goes wrong during DFU and I need to use Particle Doctor to recover the device.
And that brings me to the issue of my Bricked board. I’d been successfully “restoring” boards that weren’t working correctly most of the day and had taken one back to the office with me for further testing. After verifying again that DFU was causing the issue I went about restoring the device with Particle Doctor. I got to the first step after flashing the doctor app (Which seems to be the only thing I can successfully flash over DFU) of selecting DHCP type, when I encountered a BSOD with the error code of WDF_VIOLATION. After my computer had finished rebooting I went to put my board into DFU mode when the LED on the board went out and hasn’t come back on since. The only difference when I was in the office is that my laptop was hooked up to a docking station and thus the board was plugged into a USB hub vs directly into my laptop. Windows doesn’t recognize that anything is there when I plug it in and I’m out of ideas as to what to do next.
What does particle binary inspect give you for your binaries?
What does particel serial inspect give you about the device?
Does your USB interface work otherwise (e.g. Serial.print(), Listening Mode, …)?
When you can’t tell which mode the device is in, are you sure it’s in DFU Mode when you try flashing?
p1-tinker@1.1.0.bin
CRC is ok (5e81e1d1)
Compiled for p1
This is an application module number 1 at version 6
It depends on a system module number 2 at version 1102
P1-********-testbench.bin
CRC is ok (c9445431)
Compiled for photon
This is an application module number 1 at version 6
It depends on a system module number 2 at version 1102
I’m confused as to why it says compiled for photon when I specifically set the environment for P1, either way both binarys exhibit the same issue when flashed.
Could not get inspect device: No serial port identified
“Bricked” device doesn’t show up in Device Manager either, waiting on a good one to see how it looks.
- Serial monitor works fine, not sure about listening mode. How should I test that via USB?
- While the Colors on the LED are wrong, the flashing patterns are right in that I’ve been looking at Photons enough to know how long it takes to go from Standby to DFU mode. The colors do change and I’ve also used the Mode COMX 1440 to set them into DFU successfully. I’ll also get a ‘Flash Successful’ message when done.
How have you built that testbench.bin?
Listening Mode (e.g. particle serial inspect) uses USB Serial 
Could it be that you are using common anode LEDs or have the RGBs wired incorrectly?
I did build it in VSCode, though when I completely cleared the Target folder and recompiled I got the following.
********-testbench.bin
CRC is ok (f1ad4e86)
Compiled for p1
This is an application module number 1 at version 6
It depends on a system module number 2 at version 1102
What's interesting is that before I cleared the folder, I had set the target to P1 and recompiled but it was still reading as 'Compiled for Photon'. I also just tested going from configured for P1 to Photon and the new binary still reads as 'Compiled for P1', looks like there is a bug (or misunderstanding) in Workbench regarding 'Configure Project for a Device' and switching platforms.
Checked the schematic and it's supposed to be a Cathode and the wiring looks correct.
I'll test listening mode when I get a working board.
Device OS assumes a common anode LED, connected to 3V3, which is why your colors are weird.
This is from the SparkFun Photon RedBoard schematic, which actually uses a P1:
This is the LED that I use on my P1 and SoM boards:
https://www.digikey.com/product-detail/en/cree-inc/CLMVC-FKA-CL1D1L71BB7C3C3/CLMVC-FKA-CL1D1L71BB7C3C3CT-ND/9094273
3 Likes
Got a working board and got the following:
Platform: 8 - P1
Modules
Bootloader module #0 - version 301, main location, 16384 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1102, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 204
System module #2 - version 1102, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1102
Bootloader module #0 - version 7
User module #1 - version 6, main location, 131072 bytes max size
UUID: **** (Not sure if this is sensitive info)
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 1102
User module #1 - version 3, factory location, 131072 bytes max size
UUID: ****
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 11
Update: I've concluded that the BSOD is being caused by the serial monitor as I've experienced it twice again today, both times when I'm flashing firmware running the --follow argument. What confuses me is that I've done this before with Photons just fine.
I've determined that my DFU issue was being caused by the binaries being incorrectly compiled for the P1 even though I used the configure project command, will open up a bug report thread. Still have a bricked P1 but the upload issue was more pressing.
That is a known issue - especially when switching between Gen3 devices.
Since the Photon and the P1 are also "too similar" the compiler doesn't see any need for a full recompile and hence reuses some pre-built object files.
The standard procedure for this is to clean the project and then rebuild from scratch.
I know, that is not convenient and I have "complained" about this behaviour to Particel behind the scenes, but for the time being that's how it is.
1 Like
Good to know that this is a know issue, though I hadn't heard about it till now.
One thing I observed in my testing is that it didn't seem to matter which platforms I went between.
I went from P1 - Photon - Electron without cleaning, then Electron - P1 after cleaning, and the compile target never changed from the "Clean Build Target". (Couldn't text Gen3 as I reference pins not on the mesh devices.)
1 Like
i’m surprised you must have dodged those incredibly nagging “your space looks dirty” notifications. those little screens are worse than my mother was 60 years ago.
1 Like