8 years, 1 month ago.

Unsafe power-off corrupts filesystem?

Hi, I noticed one of the MTQ Dragonfly (B01) manuals said it is necessary to safely shut off the device by sending an AT command to the modem and waiting 30 seconds before poweroff, in order to avoid "corrupting the filesystem."

I would like to get more details on this requirement. Does the modem actually have a corruptible filesystem? How would I repair it if it got corrupted? How would I check?

I also see an mbed example for the MTQ Dragonfly's ARM that can mount the ARM's SPI flash as a SPIFFS partition, and I wonder if this is the filesystem meant in the manual.

Can anybody shed more light on (not) corrupting the MTQ Dragonfly flash filesystems?

Thanks!

Question relating to:

The MultiConnect® Dragonfly offers developers an FCC and carrier certified solution that makes connecting sensors and other edge-of-network devices quick and easy.

2 Answers

7 years, 10 months ago.

This interests me as well

7 years, 10 months ago.

Hi Brian and Vladimir,

Regarding the cellular radio's flash memory, please read the following... http://www.multitech.com/manuals/s000636.pdf Also know that there are ongoing efforts to eliminate or at least minimize such issues.

In addition to the radio's flash memory, the STM32F411 has 512KB of built in flash and the Dragonfly has an external SPI flash memory part that contains 2MB of flash.

Kind regards, Leon

The document you linked says that some modems have a recoverable flash, and some do not. Which one does dragonfly belong to? Is the radio's flash the only one that can get corrupted?

posted by Vladimir Akopyan 12 Aug 2016

The flash corruption issue that the linked document is referring to applies to the -C2 and -EV3 radio models. The -C2 is not recoverable but the -EV3 may be. Assuming you have an MTQ-H5(Dragonfly), we have not seen this corruption issue. I have not heard of any problems with the 512KB or 2MB flash but this is a complex issue and I think virtually every flash part has some susceptibility to corruption. Maybe take a look at... http://www.embedded.com/design/prototyping-and-development/4006422/Avoid-corruption-in-nonvolatile-memory

posted by Leon Lindenfelser 16 Aug 2016