Lost DeviceID

[Dejan Deletic]

I have had an mDot plugged into an EVB for a few weeks now. It is being used to develop software including communications to MultiTech MultiConnect Conduit over LoRa. Everything worked fine until a few days ago when I suddenly lost ability to receive messages sent from Conduit to my mDot.

After extensive investigation on both sides (mDot firmware and Conduit’s Node RED configuration), I found out that the culprit is mDot’s 8-byte Device ID – the one that is supposed to be unique; the one printed on the label sticked onto the microcontroller. It has somehow changed its value to 00:00:00:00:00:00:00:00.

Now that I changed my Node RED config to send messages to this new ID, everything works again. But it rises several reliability related questions.

– What caused it?
– How do I prevent/minimise future occurrences?
– How do I find out if this happens in the field?
– What would happen if more than one unit reverted to ID of 00:…:00?
– Can it be put back to factory programmed value?

Thanks,
Dejan

[Jason Reiss]

The device id is stored in flash. Open a support portal case and we can help get the id reprogrammed.

support.multitech.com

[Dejan Deletic]

That doesn’t answer any of my questions (other than the last one).

For now, I don’t really mind if one of my nodes has lost its ID, so long as I can be confident it is not going to happen once units are deployed. Re-programming it back to match what is printed on the sticker is low priority for me.

[Jason Reiss]

The flash part can be corrupt if it is not provided with enough current.
Low battery operation may have caused the memory loss.

Does the device report errors in the debug output?

[Dejan Deletic]

I don’t see any device report errors other what I send to debug output. Perhaps I should try mDot bootloader on its own? Or look into TRACE_LEVEL logs?

• This reply was modified 8 years, 2 months ago by Dejan Deletic.

[Mike Fiore]

Dejan,

Did you erase the entire flash part on your mDot at any point? The mDot configuration is saved to the flash, so this would have erased it and given you the default device ID of all 0s.

Can you post some trace level debug info from around when mDot::getInstance() is getting called? That will give us information about whether or not the flash is functioning properly.

Thanks,

Mike

[Dejan Deletic]

Mike, Jason,

I power the EVB via USB. I am not aware of any power failures that may have caused flash memory contents loss. I did not knowingly erase flash contents either.

But it does appear to be corrupted. Here is trace level info of getInstance() call:

[ERROR] File from flash wrong size. Expected 256 – Actual 1024
[DEBUG] Defaulting protected settings.
[ERROR] File from flash wrong size. Expected 1024 – Actual 0
[DEBUG] Setting to defaults.
[DEBUG] Failed to file in flash.
[DEBUG] Session to defaults.

I hope this helps us diagnose the problem, although I fear it is now too late for that.

[Author]

Posts