Today was the straw that broke my back with this BSOD issue. There was a ultra high priority order to ship 25 units overnight before UPS closed. I quickly grabbed 25 new units off the shelf and went to program them. Every 3’rd - 4’th unit my PC went BSOD showing WDF Violation on that screen. It’s bad enough to have to wait ~11 seconds for the P1 to do its first boot thing (solid white, flash white, then yellow, then white, and finally flash blue) before you can even put it in DFU mode to program it. Let alone have to wait for Windows to gather the crash info to send to MS before it will restart every 3-4 board.
Particle team… You really need to find out what is causing this BSOD on Win10. This is causing nothing but nightmares on the production floor. So much so, the boss (very pissed off) yelled at me saying “don’t you ever use another one of those dam Particle devices in another product, They are to much of a PITA to program on the floor!!!”
My Laptop, desktop and 2 production computers dedicated to programming these all get BSOD. Since then I installed a fresh copy of win 10 on my PC and laptop, and refuse to install CLI on them. I only develop OTA because of this. I have been using Win10 since the very first day you were able to download the trial. Since then I have never gotten the BSOD until installing and using CLI. This needs some serious investigation, because if you are able to kill win10 something your doing is very, very wrong.
On this issue, I have to agree with my boss. We have started using the ESP32, and thus far it’s magnitudes easier & faster to program. 3-4 seconds from boot and its flashed. Even they have a GUI app in windows to flash it. Time to get cracking on this problem.
Please fix this, I want to very much so continue to use the P1 as it personally like it allot, but without a solution for this I am going to be forced to use something else.
Hello... Yes I know that this is an option. In our case. No one here uses mac, and for sure they are not going to flip to buy one of those just to program a part for the production floor. As for the Linux side, It's not in my wheel house of knowledge. I feel that If the application allows me to develop on a PC it should also let me program it on the same with no issues.
I dont have this problem with the Particle device. Just the P1. Every P1 that we have ever used you need to wait for that boot process to finish before you flash it. If you power (a new) one up while holding the mode button down to put it into DFU mode and flash your 3 files to it
I.E.
system-part1-0.6.3-p1.bin
system-part2-0.6.3-p1.bin
p1_0.6.3_firmware_1515423979067.bin
It will not boot your firmware, however it you instead power it up wait for it to do the flashy led steps waiting until it flashes blue, then reset it and hold mode down to put it into DFU mode, Then flash those 3 files it will work just fine.
I just tested this. It takes about a second longer (near the end of green blinking) for the P1 to enter a state where it will accept the magic baud rate than it does on a photon, which is strange, because a photon accepts the magic baud rate as soon as it begins booting.
Sorry if i was not clear. When I try this with a new Photon I can power it up holding down the mode and start flashing my 3 files and all goes well. I cannot do this with a P1. I must wait until it flashes blue first. I have no idea what your referring to with the "magic baud rate"
The magic baud rate refers to a feature of all Particle devices where you can set the baud rate of the serial device to 14400 and the device will go into dfu mode. An essential feature for mass programming.
You may want to add a bootloader flash - but that should be applied via YModem (in Listening Mode).
BTW, do you get any BSODs on machines without CLI?
During what process does the WDF violation happen?
I guess it's happening while you have an active (not fully shut down) serial connection.
What's happening just before the BSOD with the device?
What software are you using in the process?
Sometimes when you first plug in the USB, and others when you start CLI flash process
Not quite sure what you mean here. But the process is here is Power board up, wait for led to flash blue, reset into DFU mode, run the flsah script which flashes the 3 files, wait for the device to reboot and verify things are good by the units onboard LCD. then power off, and unplug cables.
Nothing, I am in the process of grabbing the next new board and plugging in the PC USB cable.
I am unclear on what you are asking. These production floor computers only have 2 things installed on them. CLI & Tera-Term. Tera_Term was not even open or used last night when this was happening.
Exactly what I "expected" to hear - Whenever I saw BSODs it was while or after I had TeraTerm open. While its auto-reconnect is a nice feature, I had stopped using TeraTerm since I put the (rare) BSODs down to it.
I have been testing an Electron by cycling it power at random intervals. I had the electron plugged into a USB hub and into my Win 10 laptop but did not have either CLI or a terminal program opened for that port. I could hear the classic “connect” and “disconnect” tones on my laptop’s speaker as the power was removed and reapplied to the Electron. After a random number of these cyles, typically not too many, I would get a BSOD. I tried with different USB connection configurations with the same results.
In the past, I also had the same issue with TeraTerm connected to the device. The issue is either a fundamental problem with Windows or a problem with the way it connects to the Particle devices. I have not installed any extra serial drivers for any Particle device.
True, I noticed that as well on my Dev PC. After noticing this i installed a fresh copy of Win10 and never installed CLI since.
Normally I would agree with you that it would be a windows issue. However we make allot of products using many different embedded platforms, and until CLI we never had a BSOD issue. I would like to note here that if i do not install CLI on a PC. plugging it in and removing it quickly does not cause BSOD (at least for me).
I wonder if there’s a hidden old Particle serial driver that’s getting activated when a new device is connected. Following the instructions to remove the driver may be helpful.
Actually, just knowing if the old driver is still installed would also be a good first step to figuring out what’s happening. The old serial driver can BSOD, so knowing if that’s installed is helpful.
@rickkas7, I have no hidden drivers, only devices that are not currently connected are showing up. All drivers are Microsoft labelled. I never installed the Particle drivers on my laptop.
That’s interesting. I’ll try to reproduce the BSOD later today. We’re also reviewing the driver installation portion of the Windows CLI installer to make sure it’s doing the right thing.
I set up a P1 running 0.5.5 (to simulate a factory device), connected to a Windows 10 computer. I manually removed the hidden Particle device drivers and the device is coming up using the Windows CDC driver now. It’s running firmware that goes into SLEEP_MODE_DEEP after 30 seconds so the USB device will disconnect, then turns back on after 30 seconds.
I was under the impression that HID device drivers in Windows ran in user space (rather than kernel space)… which would make a BSOD a pretty unusual result…
There is another issue that is problematic. Once you flash it and it reboots. If you then put it in DFU mode again CLI wont see it. You need to use zadig to replace the new driver back to lisbstk to you can then run CLI.
