What happens if I flash the wrong firmware to a device using the particle cli tool? So for example if I flash a .bin file for a B5 SOM to a BSOM and vice versa?
I am also having trouble with the cli tool trying to flash a .bin file over usb.
If I try the following:
particle flash --local b5_test.bin
Then I just get no response on the terminal
Context
I have tried using cli v 3.25.0 and 3.25.1.
I have tested in our product PCBA and a dev shield.
Both particle serial list and particle serial monitor are working normally, but particle serial identify is not.
PS C:\Users\w\SB\autoPy> particle serial list
Found 1 device connected via serial:
COM5 - B5-SoM - e00fce68a2a87c56c5xxxxx
PS C:\Users\w\SB\autoPy> particle serial identify
Could not identify device: Unable to open USB device
B5SOM currently running firmware 6.1.0.
UPDATE
Ok so it works correctly if I place the device in DFU mode first. Does this mean I have a driver issue?
Generally the device will reject the incorrect binary immediately. In some cases it will be loaded onto the device, then rejected after reboot and the old firmware used.
You're using 6.1.0, but just to be sure: this is not a protected device, correct? There's a different set of rules for devices that are in a product that has device protection enabled.
Also I recommend using 6.1.1 and the latest CLI if you are using the 6.x branch.
One of the differences between --local and --usb is that local will upgrade Device OS if necessary, so that's an extra set of steps and does involve loading files from the Internet if an upgrade is necessary.
If a device can't be flashed while in operating mode, but can in DFU mode, it's possible that something in user firmware is preventing normal operation. When a device is switched between modes, it does so using USB control requests. It's possible that user firmware is interfering with this. (Device protection will also interfere with this, by design, since you can't flash a protected device locally unless protection is temporarily disabled, and this requires 6.1.1.)
The device was in a product, but even after I removed it from the product I was still seeing the behavior.
Where on the console do you enable or disable device protection for devices? Is this stored locally on the device?
Is it possible that this was a seating issue with the m.2 connector, or dirt on the m.2 connection? I tried multiple time removing and reseating the device on both the dev board and our PCBA and it was not working, but then it just started working again. Could a connection issue here prevent the cli flash command, and particle identify, but still allow serial monitor, and serial list?
I did also add it to and remove it from the product multiple times, I know that in the past, I have removed a device from a product but when I have then pushed firmware to the device it behaved like it was still in the product, ie. it pulled the product firmware. It's like it was not removed from the product correctly. I did experience this behavior yesterday also. I expect there may be a bug/delay somewhere around removing devices from a product. This is the second time I have observed this behavior.
Anyway it seems to be performing as expected now, but not 100% sure what changed it, If it is possible it was a seating issue in the connector or a dirty m.2 pin, then I feel like that might be what resolved the issue.
Device protection is an enterprise feature that can't be turned on or off. If you don't know if you have it enabled, you probably don't.
Prior to Device OS 4.0 there could be a great deal of difficulty removing and adding product devices because there was a component on both the device side (in the product firmware) and cloud side. With Device OS 4.0 and later, changing product ownership occurs only on the cloud side on a device reset, so it should be much easier.
If you are trying to diagnose a problem with a product device, it's generally easier to mark it as development device and claim it to your account (if it wasn't already) instead of moving it in and out of a product.
It seems unusual that a bad connection would cause exactly that behavior, but it's not impossible. I think the most likely scenario would be that the bad connection caused the user thread to be stuck in a waiting loop. This caused USB control requests to fail, which is why flashing failed in operating mode. The usb list commands are handled from the system thread. DFU also does not run the user app.
Certainly anything that deadlocks, such as mutex deadlock will definitely cause issues.
It's possible that blocking the loop thread from returning might have some effects. It's good practice to return from loop frequently if possible. There are some other tips in the link above as well.
I think I found the issue, I had an ADC, ADS1256 that was not working properly, and it seems like interacting with this ADC when not working was blocking both the USB control requests and also cellular connectivity.