I was thinking the same thing, but rather than particle version, add the info to particle list
1 Like
In that case, please remove the e[2Ke[1G garbage out of the output or include a clean option
particle list > list.txt gives
e[2Ke[1G. Retrieving devices...e[2Ke[1Go Retrieving devices...e[2Ke[1GO Retrieving devices...e[2Ke[1G@ Retrieving devices...e[2Ke[1G* Retrieving devices...e[2Ke[1G. Retrieving devices...e[2Ke[1Go Retrieving devices...e[2Ke[1Ge[2Ke[1G. Retrieving device functions and variables...e[2Ke[1Go Retrieving device functions and variables...e[2Ke[1GO Retrieving device functions and variables...e[2Ke[1G@ Retrieving device functions and variables...e[2Ke[1G* Retrieving device functions and variables...e[2Ke[1G. Retrieving device functions and variables...e[2Ke[1Go Retrieving device functions and variables...e[2Ke[1G
myPhoton [12345678123456781234567812345678] (Photon) is online
1 Like
Hi,
My vote is for this to be visible from user code (as well as CLI ??) - then we can simply read it remotely and publish or do whatever we need to :-))
Thanks
Graham
1 Like
Any updates on this? Has anyone done this sort of thing.
Running up against the same issues A @enjrolas, batch flashing units and not being sure about whether part1 goes through before flashing part2 has resulted in bricked units.
From my experience many units in the field operate in locations with bad WiFi and updates often fail, and can never make it back, even with the safe mode healer.
System.version() or System.versionNumber().
1 Like
Just thought Iâd mention that the more recent firmware gives more readable output:
[Hit 'v']
system firmware version: 0.4.9
Cheers,
When I connect my P1 which was purchased a while ago, the putty output is when I enter s:
modular: no
And nothing happens when v is entered.
When I use CLI with particle identify I get:
Unable to determine system firmware version```
Any ideas what the modular: no is?You could try particle serial inspect to get more info out.
But you might want to perform particle update first, since when this is a factory default P1, I think it doesnât have the modular but the monolitic firmware installed.
I tired the particle serial inspect but got the below error
C:\Users\Steve>particle serial inspect
! serial: SyntaxError: Unexpected token m```
I currently do not have easy access to get the P1 into DFU mode for the particle updateYour P1 is running manufacturing firmware pre-0.4.0 - let it connect to the cloud and it should update to a more recent firmware revision (0.4.5.) All P1âs and Photons should be running 0.4.9 or later before using the device updater.
Hi!
@mdma I would like to ask you for help⌠Occasionally, we have one of the photons in our fleet (1000+ devices) stuck in safe mode. Sometimes we manage to resurrect it by flashing system module parts/bootloader/tinker etc⌠it is always a different part/order. Sometimes we donât succeed and need to replace it.
Here is the output from two such Photons. Could you please tell me what dependency are they missing?
We run the devices connected to the Brewskey version of the cloud (not the official Particle cloud), so there is a chance there is a bug on our side in handling OTA updates.
Thank you!
Photon A:
{
"f":[
],
"v":{
},
"p":6,
"m":[
{
"s":16384,
"l":"m",
"vc":30,
"vv":30,
"f":"b",
"n":"0",
"v":11,
"d":[
]
},
{
"s":262144,
"l":"m",
"vc":30,
"vv":30,
"f":"s",
"n":"1",
"v":109,
"d":[
]
},
{
"s":262144,
"l":"m",
"vc":30,
"vv":30,
"f":"s",
"n":"2",
"v":109,
"d":[
{
"f":"s",
"n":"1",
"v":109,
"_":""
}
]
},
{
"s":131072,
"l":"m",
"vc":30,
"vv":26,
"u":"27AB07E6ABA1F2CE920BEC14DC118D430DF89DE833766C8AF6D4EAE4C05CF22D",
"f":"u",
"n":"1",
"v":6,
"d":[
{
"f":"s",
"n":"2",
"v":2008,
"_":""
}
]
},
{
"s":131072,
"l":"f",
"vc":30,
"vv":0,
"d":[
]
}
]
}
Photon B:
{
"f":[
],
"v":{
},
"p":6,
"m":[
{
"s":16384,
"l":"m",
"vc":30,
"vv":30,
"f":"b",
"n":"0",
"v":501,
"d":[
]
},
{
"s":262144,
"l":"m",
"vc":30,
"vv":30,
"f":"s",
"n":"1",
"v":207,
"d":[
]
},
{
"s":262144,
"l":"m",
"vc":30,
"vv":30,
"f":"s",
"n":"2",
"v":102,
"d":[
{
"f":"s",
"n":"1",
"v":102,
"_":""
}
]
},
{
"s":131072,
"l":"m",
"vc":30,
"vv":26,
"u":"27AB07E6ABA1F2CE920BEC14DC118D430DF89DE833766C8AF6D4EAE4C05CF22D",
"f":"u",
"n":"1",
"v":6,
"d":[
{
"f":"s",
"n":"2",
"v":2008,
"_":""
}
]
},
{
"s":131072,
"l":"f",
"vc":30,
"vv":0,
"d":[
]
}
]
}
This post explains how to decode the version number:
1 Like
Thank you! I missed that one,
So, Photon A needs 0.6.3 system module 1 - but it has it already (both s1 and s2 have 109)? Also, bootloader is version 11, which is 0.6.3. User code depends on 2008 (2.0.0) - VC reporting all flags except dependencies.
Photon B: needs sysmodule1 of version 0.6.0, but has 0.7.0. Bootloader is 1.4.4. User code needs 2.0.0.
The user code dependency is current - both were flashed with code compiled against 2.0.0.
What modules do you recommend to flash to them?
I tried flashing them first with tinker (0.4.5 and 0.6.0) and also the all system modules and bootloaders of their current versions and dependency versions. Also all in 2.0.0.
Thank you!
Since the user firmware app was compiled against 2.0.0 (ver 2008), it requires Device OS 2.0.0.
Flash Device OS 2.0.1, including system-part-1, system-part-2, and bootloader. Donât flash 2.0.0, as there is an important bug that is fixed in 2.0.1, but 2.0.1 will run your firmware built on 2.0.0 correctly.
Or rebuild your firmware to target 0.7.0 and flash only the user application.
Will try, thank you!
What bug in 2.0.0 do you mean?
We switched from 1.4.4 to 2.0.0 and after that we struggle with the photons locking up (despite SW watchdog set up). But it seems this is still present for 3.2.0, so I guess 2.0.1 contains it as well - I will document it for Particle, just need to find a reliable way how to reproduce it.
Thank you!
Oh, wait, 2.0.0 is fine on Gen 2 devices. The bug I was thinking of is specific to Gen 3:
- [Gen 3] Fix processing of modules with
MODULE_DROP_MODULE_INFOflag in the bootloader, when scheduled to be flashed by Device OS versions before 2.0.0-rc.1 #2246
So, I managed to recover the Photon B mentioned above (bootloader 1.4.4, S1 0.7.0, S2 0.6.0, user code against 2.0.0). First, I tried a lot of possible combinations of system modules and bootloaders (0.6.3., 0.7.0, 1.4.4., 2.0.0., 2.0.1, 3.2.1 etc⌠I wrote a script for it) - no luck, the json never changed, all dependencies remained the same.
Then I flashed 0.6.2 bootloader and at this moment the JSON changed, indicating bootloader version 11 (0.6.2). The exact sequence of modules how I recovered it:
bootloader-0.6.2-photon.bin (bootloader in the JSON changed to 11)
system-part2-0.6.3-photon.bin (s2 in the JSON changed to 109)
system-part1-0.6.3-photon.bin (s1 in the JSON changed to 109)
tinker compiled against 0.6.3
photon no longer in safe mode
system-part1-0.7.0-photon.bin
system-part2-0.7.0-photon.bin
bootloader-0.7.0-photon.bin
photon-system-part1@1.4.4.bin
photon-system-part2@1.4.4.bin
photon-bootloader@1.4.4+lto.bin
and finally, our user code compiled against 1.4.4 - done, unit fully working.
that separate 0.6.2 bootloader is a weird thing - until 0.7.0. the bootloader came bundled with the system modules, for some reason photon refused to load the bootloader when flashed with 0.6.X modules or separate bootloader of versions 0.7.0 and higher.
module versions:
I added a feature to the Device Inspect tool to decode the raw JSON data from the spark/status/safe-mode event, in addition to being able to decode it from a device connected by USB in listening mode.
https://docs.particle.io/tools/troubleshooting/device-inspect/
4 Likes