Device flash gets overridden by 'auto-update'

Troubleshooting
1

Hi, I can’t seem to flash a device (300037000f47373033383530) in a new batch of 500. I’ve changed to using v1.0.1. The best I can figure out is there is some new product firmware it thinks that I want to be on the device, which I really don’t want to be on the device. I want our firmware .bin to be on there.

This following debug is of us flashing it, and a few seconds later it has the ‘auto-update’ and flashes god knows what image to the device. I’d really appreciate some help, support have been quiet for 24 hours with no response and I have a production line waiting on how to fix this without going back to v0.7…

{"name":"spark/flash/status","data":"started ","ttl":60,"published_at":"2019-04-03T04:43:45.784Z","coreid":"300037000f47373033383530"}
{"name":"spark/flash/status","data":"success ","ttl":60,"published_at":"2019-04-03T04:43:51.469Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/last_reset","data":"user","ttl":60,"published_at":"2019-04-03T04:44:24.483Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/diagnostics/update","data":"{\"device\":{\"system\":{\"uptime\":27,\"memory\":{\"total\":83200,\"used\":44312}},\"network\":{\"connection\":{\"status\":4,\"error\":0,\"disconnects\":0,\"attempts\":1,\"disconnect\":0},\"signal\":{\"rssi\":-43,\"strength\":100,\"quality\":100,\"qualityv\":49,\"at\":1,\"strengthv\":-43}},\"cloud\":{\"connection\":{\"status\":1,\"error\":0,\"attempts\":1,\"disconnect\":0},\"disconnects\":0,\"publish\":{\"rate_limited\":0},\"coap\":{\"unack\":0}}},\"service\":{\"device\":{\"status\":\"ok\"},\"coap\":{\"round_trip\":2652},\"cloud\":{\"uptime\":2,\"publish\":{\"sent\":2}}}}","ttl":60,"published_at":"2019-04-03T04:44:24.486Z","coreid":"300037000f47373033383530"}
{"name":"version-p1","data":"20190402-1601-01-P11.0.1","ttl":60,"published_at":"2019-04-03T04:44:24.484Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/app-hash","data":"228A5432A15708685E9E3CAE0172DC26A8A40C1C1463AE2D795160EE1DDB0F66","ttl":60,"published_at":"2019-04-03T04:44:26.049Z","coreid":"300037000f47373033383530"}
{"name":"spark/status","data":"auto-update","ttl":60,"published_at":"2019-04-03T04:44:26.081Z","coreid":"300037000f47373033383530"}
{"name":"spark/flash/status","data":"started ","ttl":60,"published_at":"2019-04-03T04:44:27.331Z","coreid":"300037000f47373033383530"}
{"name":"spark/flash/status","data":"success ","ttl":60,"published_at":"2019-04-03T04:44:49.264Z","coreid":"300037000f47373033383530"}
{"name":"spark/status","data":"offline","ttl":60,"published_at":"2019-04-03T04:45:04.531Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/last_reset","data":"user","ttl":60,"published_at":"2019-04-03T04:45:08.548Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/diagnostics/update","data":"{\"device\":{\"system\":{\"uptime\":16,\"memory\":{\"total\":83200,\"used\":42432}},\"network\":{\"connection\":{\"status\":4,\"error\":0,\"disconnects\":0,\"attempts\":1,\"disconnect\":0},\"signal\":{\"rssi\":-45,\"strength\":100,\"quality\":100,\"qualityv\":47,\"at\":1,\"strengthv\":-45}},\"cloud\":{\"connection\":{\"status\":1,\"error\":0,\"attempts\":1,\"disconnect\":0},\"disconnects\":0,\"publish\":{\"rate_limited\":0},\"coap\":{\"unack\":0}}},\"service\":{\"device\":{\"status\":\"ok\"},\"coap\":{\"round_trip\":606},\"cloud\":{\"uptime\":0,\"publish\":{\"sent\":2}}}}","ttl":60,"published_at":"2019-04-03T04:45:08.551Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/app-hash","data":"3FC10E3A760DD114FBBDA5B548ADEFEA9731ACA70BCC245DCDE95817C8F9869F","ttl":60,"published_at":"2019-04-03T04:45:09.791Z","coreid":"300037000f47373033383530"}
{"name":"schedule-zone-sync/300037000f47373033383530","data":"null","ttl":60,"published_at":"2019-04-03T04:45:08.549Z","coreid":"300037000f47373033383530"}
{"name":"hook-sent/schedule-zone-sync/300037000f47373033383530","data":"","ttl":60,"published_at":"2019-04-03T04:45:10.530Z","coreid":"particle-internal"}
{"name":"hook-response/schedule-zone-sync/300037000f47373033383530/300037000f47373033383530/0","data":"{\"error\":true}\n","ttl":60,"published_at":"2019-04-03T04:45:10.693Z","coreid":"particle-internal"}
{"name":"datasync/complete","data":"{\"registered\": false}","ttl":60,"published_at":"2019-04-03T04:45:10.967Z","coreid":"300037000f47373033383530"}
{"name":"status/tzchange","data":"{\"actual\": -4.000000, \"new\": 0.000000}","ttl":60,"published_at":"2019-04-03T04:46:02.853Z","coreid":"300037000f47373033383530"}
{"name":"deviceLocator","data":"{\"w\":{\"a\":[{\"m\":\"fc:37:2b:4c:64:c1\",\"s\":-34,\"c\":7},{\"m\":\"fc:37:2b:42:e5:41\",\"s\":-45,\"c\":9},{\"m\":\"9e:ad:97:72:45:9b\",\"s\":-64,\"c\":11},{\"m\":\"10:9a:dd:8a:48:c1\",\"s\":-70,\"c\":11},{\"m\":\"00:18:0a:81:91:56\",\"s\":-68,\"c\":1},{\"m\":\"fc:dd:55:11:6b:9c\",\"s\":-67,\"c\":3}]}}","ttl":60,"published_at":"2019-04-03T04:46:03.547Z","coreid":"300037000f47373033383530"}
{"name":"hook-response/deviceLocator/300037000f47373033383530/0","data":"22.693952,113.80866510000001,20","ttl":60,"published_at":"2019-04-03T04:46:03.703Z","coreid":"particle-internal"}
2

For us it’s hard to tell what of that log is expected and what not since we have no clue what firmware you want on your device and what not.
No idea whether your firmware triggers any of the webhooks we see in that log.

Without that background I’d assume what we are seeing in the top part of the log is an attempt of the system to upgrad the device OS to actually fit the application firmware target version.

So some more background may help.

If this is the one and only device that behaves like this, could it be that this device is not really a completely fesh device?
Where did you get it from?

3

Yes, that device ID has been added to a product. You’ll either need to remove the device ID from the product or mark it as a development device to prevent automatic firmware updates.

2 Likes
4

how do i see what product its associated with? I can’t find anything anywhere.

5

Hi @rickkas7!
I’m unsure how this brand new chip has been associated with a product.

  • I have one product that I experimented with over a year ago (Product ID 217 / smartfire-bbq-controller-v01) It only has one device (310022000747343337373738) associated to it.

So, I can’t see what product(s) a device (300037000f47373033383530) has been associated with, nor how to remove it and continue happy life flashing this batch like we normally do. Any assistance on this black magic would be appreciated.

In the meanwhile I’m going to go back to 0.7.0 and get the team rolling on the other 499, hopefully they work.

6

Hi Scruff,

  • Brand new chip, came as part of a tape of 500. It’s why I’ve thrown out the boat anchor before more chips are effectively bricked.

Fair question re what’s my firmware and what was the process.

The following segment was me triggering a flash of a compiled 1.0.1 bin with the target p1 running 1.0.1. The only webhook that my code gets to briefly get out is the version-p1, which is how our self rolled firmware system (since cores were a thing) knows whether or not to trigger an update. It’s the last thing in the setup() block. It’s important to note not only is our system logging letting it through as it knows its using the right binary, the same auto-update occurs if our system is killed and not running. The subsequent spark/device/app-hash seems to be pulling the trigger of auto-update.
Naturally anything starting with spark/ is the particle cloud or particle firmware.

{"name":"spark/flash/status","data":"started ","ttl":60,"published_at":"2019-04-03T04:43:45.784Z","coreid":"300037000f47373033383530"}
{"name":"spark/flash/status","data":"success ","ttl":60,"published_at":"2019-04-03T04:43:51.469Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/last_reset","data":"user","ttl":60,"published_at":"2019-04-03T04:44:24.483Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/diagnostics/update","data":"{\"device\":{\"system\":{\"uptime\":27,\"memory\":{\"total\":83200,\"used\":44312}},\"network\":{\"connection\":{\"status\":4,\"error\":0,\"disconnects\":0,\"attempts\":1,\"disconnect\":0},\"signal\":{\"rssi\":-43,\"strength\":100,\"quality\":100,\"qualityv\":49,\"at\":1,\"strengthv\":-43}},\"cloud\":{\"connection\":{\"status\":1,\"error\":0,\"attempts\":1,\"disconnect\":0},\"disconnects\":0,\"publish\":{\"rate_limited\":0},\"coap\":{\"unack\":0}}},\"service\":{\"device\":{\"status\":\"ok\"},\"coap\":{\"round_trip\":2652},\"cloud\":{\"uptime\":2,\"publish\":{\"sent\":2}}}}","ttl":60,"published_at":"2019-04-03T04:44:24.486Z","coreid":"300037000f47373033383530"}
{"name":"version-p1","data":"20190402-1601-01-P11.0.1","ttl":60,"published_at":"2019-04-03T04:44:24.484Z","coreid":"300037000f47373033383530"}
{"name":"spark/device/app-hash","data":"228A5432A15708685E9E3CAE0172DC26A8A40C1C1463AE2D795160EE1DDB0F66","ttl":60,"published_at":"2019-04-03T04:44:26.049Z","coreid":"300037000f47373033383530"}

Then we have the protagonist of this drama:

{"name":"spark/status","data":"auto-update","ttl":60,"published_at":"2019-04-03T04:44:26.081Z","coreid":"300037000f47373033383530"}

Not me, not our system, something related to particle products.

Everything after that is what I presume is the blank 1.0.1 tinker.

1 Like
7

7 days and counting. 500 chips sitting at the manufacturer waiting to be flashed.

I’m going to try just using 0.7.0 but this is a pretty big deal that

a) the particle system seems to be acting out like HAL deciding arbitrarily that a chip is associated with a product (not in my console)

15
152866×904 263 KB
.

b) 7 days, no reply from support.

that’s not good enough from any company.

8

Hey there @mterrill –

Going to send you a PM since I want to be sensitive to sharing what may be private information in a public forum. Will let you know when I have done so.

1 Like
9

Done! I am also re-categorizing this to a Troubleshooting request, since our developer support team spends some % of their time in the forums and generally looks for requests in that category.

10

Thanks, have replied. Seems someone else has claimed our device ID’s from our tape and reel of 500

PS, I’ve double checked that 300037000f47373033383530 is in the email list of 500 device IDs from our last order.

11

Taking a look around console.particle, noticed you can bulk add device IDs. Curious to know how it validates that those device IDs belong to your account… ? A siphash validation code per device id, hashed on the primary login email of the account, the device ID and a private salt would seem to be a good idea…

35
351220×910 76 KB

1 Like
12

Lastly, tried just flashing 0.7.0 to a brand new device via remote desktop to china. No joy.

sdb-190409-elite-tot-swim [220022001547373033383530] (Product 1687) is online

Product 1687. That bs association needs to be removed pronto for our full batch. None of them should be associated to any product. Will, you have the full list in DM.