SPIFFS

Home Forums mDot/xDot SPIFFS

Tagged: 

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #12775
    Michael
    Participant

    What are, and how do I get rid of, various “SPIFFS” read and write failure error messages?

    (these come out of the USB/debug from the UDK2 with mDot installed)

    #12776
    Andrew Lindsay
    Participant

    Never seen these messages, what do they look like?

    #12777
    Michael
    Participant

    Here’s one (it appears in the Linux terminal window)
    [ERROR] SPIFFS_read failed -10004

    Here’s another

    [ERROR] SPIFFS_write failed -10015

    • This reply was modified 8 years, 6 months ago by Michael.
    #12787
    Andrew Lindsay
    Participant

    I’m guessing SPIFFS means something like SPI Flash File System which would indicate the external flash chip isn’t working on the mDot.
    Also, ensure you’ve not accidentally used on of the I/O pins PC_6, PC_7, PC_8, PC_10, PC_11 or PC_12 as these are used for the flash chip.

    Andrew

    #12789
    Michael
    Participant

    Hi Andrew,

    Yes, I looked up SPIFFS and saw it had something to do with the Flash file management, but I don’t do anything directly with it (other than to drag and drop my files to the mDot). Nor do I touch any of the pins you mention. (I don’t think they are even available physically unless I somehow damage the mDot board).

    I do see the problem on multiple mDots, (but not all of them) and it has only started recently.

    Thanks for your time/effort so far.

    Mike

    #12790
    Michael
    Participant

    Here’s a typical boot-up

    [ERROR] SPIFFS_read failed -10004
    [ERROR] File from flash wrong size. Expected 256 – Actual 128
    [INFO] Setting Config
    [INFO] setting Join mode
    [TRACE] Join Network – OTA
    [TRACE] Rx Channel Frequency: 923300000
    [TRACE] Tx High BW Frequency: 903000000
    [INFO] Saving Config
    [DEBUG] Saving config to flash
    [ERROR] SPIFFS_write failed -10015

    #12800
    Mike Fiore
    Blocked

    Michael,

    Andrew is correct. There is a filesystem implementation running on the external flash on the mDot. It sounds like there may be an issue with the external flash on your mDot. If this is the case, your configuration may not be getting read from or written to the filesystem correctly. Please open a support case (if you haven’t already) on our portal.

    https://support.multitech.com/support

    Cheers,
    Mike

    #12826
    Michael
    Participant

    Yes, I have opened a support case and gotten a response that seems to suggest I may have suffered a low-voltage condition during operation.

    I have operated (for short periods – 15-30 mins) from one of those external cellphone battery chargers (brick) but it was always fully charged at the time.

    Anyway, the support case provided some additional steps I will attempt to perform.

    #14404
    Andrew Lindsay
    Participant

    Can you share the steps to resolve this issue as I am now seeing it on one of my mDots.

    Thanks

    Andrew

    #14412

    Hi Andrew,

    We have seen occasions where the flash memory becomes corrupted when the mdot is run with a power source below 2.7v.

    To fix the flash corruption, you need to erase it and re-program the DevEUI found on the label using some debug firmware. Please open a support case at https://support.multitech.com/support so we can provide you with the debug firmware and additional instructions.

    Kind regards,
    Leon

    #14422
    Andrew Lindsay
    Participant

    If someone has already opened a support call, can they please post the information here. I’ll only raise a support call as a last resort and would expect my mDots to be replaced.

    Someone must have the information, why the secrecy? This is supposed to be a support forum for the Multitech products afterall.

    Just share the info for all to see.

    Thanks

    Andrew

    #14436

    Hi Andrew,

    Since I cannot attach firmware in this forum, I have made it available on our FTP site at: https://webfiles.multitech.com/engineering/diagnostic-code/mDot/
    Be sure to choose the mdot debug version that corresponds to the frequency band of your target mdot (915Mhz or 868Mhz). The frequency band is restored as part of this process.

    Below are the instructions you will follow to erase flash and reprogram the mdot. Please note that without the debug firmware you can erase the flash but you cannot reconfigure the DevEUI and the frequency band will remain in the erased state.

    With the debug firmware you will need to connect a terminal to the debug pins at 115200 and hit enter while resetting the mdot to enter the bootloader.

    Issue “erase” to clear the flash memory.

    > erase

    Reset the device. Then on the command port program the DevEUI from the label on the mdot.

    > AT+DI=0011223344556677
    > AT&WP

    At this point, flash memory is restored and you can reload the application. You can find the mdot AT command firmware application at…

    Downloads

    Kind regards,
    Leon

    #14442
    Andrew Lindsay
    Participant

    Thank you Leon,

    I’ll give this a try.

    Andrew

    #23372
    Heath Raftery
    Participant

    For the record, it seems the mDot spits out [ERROR] SPIFFS_remove failed -10002 when you change the join mode, but that doesn’t seem to be an issue. Had me running a goose chase for a while.

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.