Gen3 hardware/firmware interoperability (i.e. can I flash Xenon's Device OS onto Boron hardware?)

Firmware Device OS
1

I understand that I cannot have multiple gateway hardware devices on a single mesh. That’s a problem because I want to test my mesh (composed of an Argon + two Xenon) with an additional mesh node and all I have is a Boron.

Can I flash Xenon-based Device OS onto a Boron and reasonably expect not to break anything? I don’t need access to any of the pins, I just need the node to generate Mesh and Cloud traffic.

My biggest concerns are that either I won’t have Cloud access because of a keys situation, or that there is a schematic incompatibility which would result in a FET being held open because of discrepancies between Xenon and Boron GPIO default settings.

Thoughts?

P.S. Of course, what I really want to do is be able to configure my Boron never to use its modem and instead participate as an equal mesh-only member. But according to Using boron as mesh-only device, this isn’t being considered right now.

2

Nope, that can't be done. However, you can add a Boron to an existing mesh via CLI and that should "degrade" the Boron to virtually being a Xenon.

2 Likes
3

Cool! One question, though. In Using boron as mesh-only device - #6 by ScruffR, you said "without the implementation of the HA feature there is currently no way for a potential gateway device to join an existing network." and I guess I assumed that the statement was still valid. Does that mean that the codebase has matured to allow this now?

Or is adding a Boron to mesh via CLI deactivating the "potential" part of that clause?

4

That's why this can't be done via the app as the app can't degrade the device CLI via DFU mode can tho' - so it loses the potential to become a gateway in that mesh.

So yes, to your concluding question.

1 Like
5

Unfortunately, in testing this doesn't seem to work. On the very first time the Boron is bound to my mesh, it connects. However, after that when it boots the device goes straight to blinking-blue mode. So there's some boot routine in the Boron which prevents this from proceeding after a reboot.

I suspect it's because I have no LTE subscription, and that therefore it might be possible to change the system thread mode so that it doesn't look for the LTE connection on boot. Once it's running, maybe I can manually turn on/connect the mesh. Thoughts?

6

You may need to set the “setup done” flag in your code - CLI is not doing this.

#include "Particle.h"
#include "dct.h"

SYSTEM_MODE(MANUAL);

void setup() {
    const uint8_t val = 0x01;
    dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);

    // This is just so you know the operation is complete
    pinMode(D7, OUTPUT);
    digitalWrite(D7, HIGH);
}

This needs to be executed only once.

1 Like
7

This was the solution. So to recap my process for anyone who gets this far:

  1. Use the Particle app to claim the Boron (this can't be done from the CLI because there's no internet connection yet)
  2. Add the Boron to a mesh via the CLI, e.g. particle mesh add e00fce680f6255aab112233c argon, where e00fce680f6255aab112233c is the Boron's ID as reported by particle identify.
  3. Place Boron into DFU mode
  4. Compile and flash the below code (using particle flash --usb ...)
  5. Reboot
  6. Flash tinker with particle flash --usb tinker
  7. Reboot

At this point, I see the Boron breathing cyan and console.particle.io shows the Boron device as online.

#include "Particle.h"
#include "dct.h"

SYSTEM_MODE(MANUAL);

void setup() {
    const uint8_t val = 0x01;
    dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);

    // This is just so you know the operation is complete
    pinMode(D7, OUTPUT);
    digitalWrite(D7, HIGH);
}

// loop() runs over and over again, as quickly as it can execute.
void loop() {
  // The core of your code will likely live here.

}
1 Like