Binds a production device to application firmware
Device
Available for use in Factory Firmware only
| Name | Type | Description |
|---|---|---|
| testSuccess | Bool |
Whether the device has passed (true) or failed (false) your tests, and so whether it should be blessed
|
| callback | Function |
Function to be called on completion of the blessing process
|
Nothing
This method can only be used only Electric Imp customers’ production lines as part of the factory testing process. It is the means by which an imp-based device under test (DUT) is blessed: the point at which Electric Imp impCloud™ servers know that the unit should be assigned to its appointed Production Device Group and sent the application firmware that has been deployed to that Group.
The first argument should be true or false, representing the success or failure of the manufacturer’s own tests of the hardware.
If the testSuccess value is true, the blessing request is sent to the server (and the server.bless() function returns). When the server responds, the function passed into the callback parameter is executed and passed a single argument: true or false, according to whether the blessing request was successful or failed. The DUT’s LED is now turned solid green for success, or solid red for failure. In this case, the LED is set when the callback is triggered, not when server.bless() returns.
If the testSuccess value is false, the failure is logged at the server, and server.bless() returns. The DUT’s LED is turned on solid red immediately to indicate failure. The blessing completion callback is still made, but with false passed as the callback’s argument.
This callback can be used for additional indications of test pass or fail, for example using connected hardware or a beep alert.
If the device’s target Production Device Group is set to download its application firmware upon blessing (this is the default), then two seconds after the callback is triggered, the server sends the DUT a restart signal. This forces the DUT’s Squirrel Virtual Machine to restart, causing the DUT to fetch the production application firmware. Any operations you include in the post-bless callback must complete within this time or prevent the imp from going idle. For more detailed guidance, please see Writing, Testing And Using Factory Firmware.
Note The production device (ie. the blessed DUT) does not have an agent at that point. Its agent will not be instantiated until the device is activated by the end-user through a BlinkUp operation.
Production devices can be re-blessed at any time, provided the blessing targets a Production Device Group on the same account. To move a device from impCentral’s Production Zone to the Test Zone, you will first need to unbless the device.
imp001 card blessing — manually putting an imp001 ‘factory imp’ into each DUT to test and bless the DUT — is no longer supported. When called on an imp001, server.bless() will return immediately and pass the failure condition into the callback function.
Note This does not apply to imp001-based DUTs which are configured using a BlinkUp™ fixture.
The following code provides minimal factory firmware for a Factory BlinkUp Fixture. Here, the fixture is an imp003 breakout board with an LED on pin Y. Every ten seconds the fixture will start the BlinkUp procedure automatically. The target device under test (DUT) will automatically and immediately be blessed as soon as it runs this code. The LED on the DUT (not the fixture) will turn solid green indicating pass/bless, or turn solid red indicating fail/no blessing.
For an expanded example, please see the imp API Cookbook Recipe Factory Firmware.