Hi all, I’ve just had one or possible two borons randomly unpaired on me.
1st instance:
over the weekend we were testing a bunch of new hardware with known good firmware(2.0.1). These tests were running perfectly until one boron stopped sending data at about 5:04 last night. when we came in this morning the said boron kept blinking blue, awaiting pairing. We could pair it from the phone successfully, and the boron has been running and transmitting fine ever since. This still is not acceptable as we will be fielding these devices later this week.
2nd instance:
I also was doing some power measurements on a boron last week, and when I came in and turned it on today, that one also thought it was unpaired… I thought I might have picked up the wrong board so I went and grabbed another one… later on I repaired it and found that it too was fine and just decided to unpair by itself? I guess I can’t count this one as much, it wasn’t really in a controlled environment so I can’t say that something else didn’t happen to it.
could this have something to do with the new billing plan? have there been any changes on the billing/sim card end over the weekend?
Thanks marek, it does look like this… one quick question… as I said before, when we field devices- we don’t have access to them so I’m looking for a good way to prevent this rather than fix it
if I use the code from you’re link:
const uint8_t val = 0x01;|
dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);|
every time right before I connect to cloud… then I would never hit this problem correct? No? is there any drawback to doing this?
I would avoid constantly writing to DCT. Instead, I’d flash a firmware that sets this value (ideally during the manufacturing process, per our recommendations) and then revert to your production firmware. The setting made in firmware is persistent.
I understand that this area is supposed to be persistent but it does seem to get changed randomly on me. I suppose that you’re worried about writing the same section of flash every few minutes… that’s a valid concern . we boot our devices every 5 minutes so that section would only last about a month ;).
if i could do something like:
if(setup_done != done)
dct_write_app_data…
this way^ I only write it when I need to and protect the flash. I’m gonna test this a bit, and see if it does no harm
As mentioned already in another thread, what is the use of that setup-done flag now after mesh support has been abandoned?
Core, Photon, P1, Electron, E-Series never needed it before and without mesh there seems to be little difference between these and Gen3 IMHO.
ok- so I tested the following code in my setup, before particle.connect, and it seems happy, am I missing something here? is there any huge risk to doing this? I can’t really think of a reason this should be flagged if I’ve already claimed the device…
uint8_t val =0;
dct_read_app_data_copy(DCT_SETUP_DONE_OFFSET, &val, 1); //reads flag- should change val to 1
if(val != 0x01)
{
val = 0x01;
dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1); //setup done if not correct
Serial.println("reset dct setup flag");
}
This strikes me as complex compared with simply creating a release flow that sets the flag in a setup firmware application and then flashes Production firmware as-is.
