P2 & device os 5.0.1 vs 5.3.0

Firmware
1

hello

we just got some new boards with a p2 and in the meantime device os 5.3.0 came out. i have some trouble getting started with 5.3.0…

please see below the code that works under 5.0.1 (on the p2 eval board): led is white and i see logging over usb/serial

compiled the exact same code on the exact same board but using the 5.3.0 tool chain: there is no logging and the led is blinking blue

what do i need to change in 5.3.0 to get this to work?

thanks
frank

#include "Particle.h"


STARTUP(System.enableFeature(FEATURE_DISABLE_LISTENING_MODE));
SYSTEM_MODE(SEMI_AUTOMATIC);

SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(115200, LOG_LEVEL_ALL);

const char *serviceUuid =   "6E400021-B5A3-F393-E0A9-E50E24DCCA9E";
const char *rxUuid =        "6E400022-B5A3-F393-E0A9-E50E24DCCA9E";
const char *txUuid =        "6E400023-B5A3-F393-E0A9-E50E24DCCA9E";
const char *versionUuid =   "6E400024-B5A3-F393-E0A9-E50E24DCCA9E";

unsigned long next;

void setup() {

    delay(10s);

    char buf[32];
    char name[32] = "Pseries-000230";

    hal_get_device_secret(buf, sizeof(buf), NULL);

    BLE.setProvisioningSvcUuid(serviceUuid);
    BLE.setProvisioningTxUuid(txUuid);
    BLE.setProvisioningRxUuid(rxUuid);
    BLE.setProvisioningVerUuid(versionUuid);

    // ---------Setup device name---------
    BLE.setDeviceName(name, 14);

    // ---------Set company ID---------
    // we (can) use particle company id
    BLE.setProvisioningCompanyId(0x0662);

    // ---------BLE provisioning mode---------
    BLE.provisioningMode(true);

    Log.info("P2 BLE test...");

    Log.info("Mobile secret: %s",buf);
    
    Log.info("Set name to: %s",name);

    next = millis() + 5000;
}

void loop() {

    if(millis() > next) {
        next += 5000;
        Log.info("BLE provisioning mode: %d", BLE.getProvisioningStatus());
    }

    if (WiFi.hasCredentials()) {

        if (!Particle.connected()) {

            Particle.connect();
        }
    }
}
2

Are you using Particle Workbench and did you flash your firmware (and possibly Device OS) over USB?

If so, the problem is that Workbench does not upgrade all of the necessary components of Device OS. In this case, it’s probably the bootloader. The device is trying to get online to upgrade the bootloader OTA, but the device does not have Wi-Fi credentials so it’s going into blinking dark blue (listening mode).

See Local build and flash and scroll down and click to expand More about changing the Device OS version for how to solve this problem. The basic idea is to upgrade Device OS using Device Restore USB before flashing your firmware.

3

ah, great, that worked!

i guess we need to do this in the factory also? what does it actually do?

right now, with p1, we use flash system part1, system part 2 and our application (per dfu) and then flash the bootloader (per serial). see below. will this work with the p2? or what needs to change?

thanks,
frank

let tests = p1adaptor()
  .then((adaptor) => {
    p1port = adaptor
    return (identifyp1(p1port))
  }).then(() => {
    return (osversionp1(p1port))
  }).then(()=> {
    return (dfumode(p1port))
  }).then(()=> {
    return(flashdfup1(config.systempart1))
  }).then(()=> {
    return(flashdfup1(config.systempart2))
  }).then(()=> {
    return(flashdfup1(config.application))
  }).then(()=> {
    return(delay())
  }).then(()=> {
    return(p1adaptor())
  }).then((adaptor) => {
    p1port = adaptor
    return (identifyp1(p1port))
  }).then(()=> {
    return(flashserialp1(p1port, config.bootloader))
  })
4

That general process will work, except:

  • The P2 only has one system part.
  • There are two bootloaders, bootloader and prebootloader-part1. The prebootloader-part1 does not change often, but could in the future.
  • Do not under any circumstances flash prebootloader-mbr. The device will never be able to boot again because it contains device-specific encryption keys for SecureBoot.
  • Be really careful about flashing the user binary by DFU directly. The address of the user binary moves based on the size of the binary, so it’s not a fixed address. The .bin file itself contains this address, or it could be calculated based on the file size and sector alignment.

See P2 flashing for more details.

5

thanks for all the info rickkas7,

the device os parts can be found here: device os files and contains: bootloader.bin, system-part1.bin, prebootloader-part1.bin, tinker.bin

we need to flash all over usb:

we first dfu flash system-part1.bin and our application and then serial flash bootloader.bin and prebootloader-part1.bin?

our application.bin is created by your plugin in visual studio: what exactly do you mean by “Be really careful about flashing the user binary by DFU directly”? is this going to work?

thanks
frank

6

we first dfu flash system-part1.bin and our application and then serial flash bootloader.bin and prebootloader-part1.bin?

Yes, that will work.

“Be really careful about flashing the user binary by DFU directly”

Flashing directly from Workbench, using particle flash --usb, or particle flash --serial from the Particle CLI will work properly.

The issue is if you are flashing directly using dfu-util in DFU mode, because the address you flash to changes based on the size of the binary. The other tools understand this and change the start address based on the address in the .bin file.

7

thanks again, so fast, great

our factory stuff is based on and uses your node code. we do something like:

const flashcommands = require('particle-cli/dist/cmd/flash')

new flashcommands().flashDfu({ binary: part.folder + path.sep + part.file, factory: false, force: false})

will that do it correctly?

thanks again for all you help
frank

8

Yes, that will work.

9

nice!

10

hi rickkas7,

one more question: so far i got the device os files from the particle cli installation. i just updated to the latest greatest but only find: device-os-flash/binaries/5.1.0/p2/p2-system-part1@5.1.0.bin

i do not see the 5.3.1 version. where can i find these?

thanks
frank

11

You should get them from the Device OS release site. The Particle CLI will always lag behind that.

12

great, thanks!