Xenon firmware on a Argon/Boron

[kenmacd]

Is it possible to install the Xenon fw on an Argon?

If not how close are they if I wanted to try to build one that would work? and how risky would it be to try?

[mstanley]

Hey Kenmacd,

Thanks for the question. All mesh devices are built inherently similar–similar enough that there shouldn’t be a need to flash firmware from one to another. The only real differences in these devices are their wireless connectivity abilities.

As such, I suppose a better question to start this off is what is the goal you’re intending to accomplish by putting Xenon firmware on an Argon or Boron? I suspect you’re trying to use an Argon or Boron as a node, but want to verify this first.

[kenmacd]

You got it. I have some Xenons, one using an Ethernet FeatherWing to connect out. I’d like to be able to use an Argon as a non-gateway node on the network.

Are you suggesting it might be doable just through configuration? (even if not through the app).

[mstanley]

In a sense, yes. There are a number of features that exist deep within the firmware that are not yet being leveraged through our interfaces yet. There’s a number of reasons for this–one is the matter of different UX flows that would need to occur (which can get complicated fast, once you’re considering variables of whether or not your gateway can be just a node now). There’s also some backend logic that needs to be accounted for on this as well.

So the firmware does have accommodations for this at a low level, and to my understanding, we do intend to flesh it out, but I’m afraid something like this is a little lower on the priority list simply because there are other new features that we have planned in Q1 that are more commonly requested (such as NFC and BT APIs).

With that said, in regards to your particular circumstance, I don’t believe there’s any way for us to bypass the UX flows and/or API logic accommodations that need to happen. So while it is on the todo list.I’m not sure it’ll be available soon.

One consideration you could consider, though, is actually swapping your Argon and Xenon. The featherwing should support Argons being used as an ethernet-only gateway just like the Xenon. From there, you could make use of the Xenon as just a node in this configuration.

[kenmacd]

Thanks for all the info.

The complications around gateway or not, and backend requirements, is why I initially wanted to just flash something that would make it 'be' a Xenon. Then I wanted to eventually use the ESP32 for some custom code

I did consider swapping the Argon and Xenon, and I guess that would work in my setup temporarily. Is there a way to do that with the existing network, or would I have to start from scratch?

I don’t believe there’s any way for us to bypass the UX flows and/or API logic accommodations that need to happen

Just to help my understanding. Where there's a lot of open-source stuff here, what parts would keep this from working if I was to build things manually? Or I guess more generally ,what makes a device with these chips a 'particle' device vs any old nRF52840 board?

[mstanley]

All good questions. I believe these are better answered by @avtolstoy who could give you the specifics and also elaborate on complications of flashing different mesh firmwares on other mesh devices.

[ScruffR]

@kenmacd

what makes a device with these chips a ‘particle’ device vs any old nRF52840 board?

A part-answer to that is

• The entire device OS that's incorporating all the fundamentals to communicate with the Particle cloud and program the device as intended by Particle (including device and management)
• Particle provisioning to allow the specific device to connect to the Particle services

[kenmacd]

Thanks @ScruffR. I’m still now curious where the proprietary bits live. device-os is on Github, so I’m not yet sure why I couldn’t flash a xenon version to an argon (or further than that, to any board). Is there a key burned in somewhere (if so I’d like to know how to back it up)? Or a ROM that’s runs under device-os?

Hopefully @avtolstoy can provide info on some of the more technical details (and maybe they’re worth documenting either in the reference documents, or at least in the Readme.md on github (cc: @rickkas7))

[ScruffR]

@kenmacd

Is there a key burned in somewhere (if so I’d like to know how to back it up)?

That's what the provisioning part is about. Each device has a unique ID and that ID must be registered with Particle in order to talk to the cloud.
Also there is a claiming process during which the devices (when provisioned) can exchange keys with the cloud to encrypt the data traffic.

[kenmacd]

@ScruffR

Each device has a unique ID and that ID must be registered with Particle in order to talk to the cloud.

Do you know where this ID is stored?

[ScruffR]

For Gen1 & Gen2 this question was (somewhat) answered here

Is it possible to change Device Id?

The device IDs are generated based on the hardware IDs of the STM32 microcontroller and cannot be changed. Each ID is associated with an account with a public/private key pair along with access tokens. So by simply knowing someone’s device ID will not give you access to their Core. We are currently thinking about using names instead/in-additon to the device IDs to make things easier. Hope this helps!

Device ID Question - Where is the device ID stored? And what are the priv/pub keys for?

Hey Guys, I just have one quick question, how is the Device ID stored on the Photon? Would it fused in via a OTP region? After completely erasing the entire Photon, including the boot loader, then getting it back up again, it still remembered my device ID. One more question, what are the pub/priv keypair used for? As I understand there are 3 keys? The device priv and pub, and the server’s pubkey, I assume the server’s pubkey is for SSLing communication to and from the Particle Servers?

and for Gen3 it'll be not too different.

And no, you can't clone a device ID as it is a unique number directly related to a hardwired ID in the silicon which the manufacurer of the controllers provides to Particle in order to provision their devices. Any attempt to cicrumvent that (if at all possible) won't be supported by this community.

BTW

@kenmacd

I’m not yet sure why I couldn’t flash a xenon version to an argon

For starters, there are some not-exposed but internally used pins that will be mapped differently.
e.g.

ANTSW1
ANTSW2
BATT
PWR
CHG
NFC_PIN1
NFC_PIN2
TX1
RX1

While the port/pin mappings seem to be the same (apart from the ones only available either on Argon or Xenon) the internal numbers don't match up potentially causing incompatibilities with application code.
See https://github.com/particle-iot/device-os/blob/v0.9.0-rc.3/hal/inc/pinmap_hal.h#L128

[kenmacd]

@ScruffR

for Gen3 it’ll be not too different.

Thanks @ScruffR. With those pointers I did some spelunking and came up with a device_ID that's burned in to the chip's 64-bit 'Factory Information Configuration Register (FICR)' DEVICEID[] (section 7 in the chip reference), and a serial number that seems to be written to the a OTP section of the flash chip. There's also a secret but I'm not sure if it's only for bluetooth or not.

I'm not yet sure why there's both an ID and serial (and I wasn't before when I saw it on the online console), but I'm guessing at least the serial list is kept in the backend, and maybe the device id list as well, so it's seeming like it wouldn't be easy to convince the backend it was a Xenon.

Well. I guess for now I'll swap things around to use the Argon for the gateway and hang an external ESP32 off a Xenon instead.