[ERROR] update_firmware: Failed to back up current firmware

Home Forums mDot/xDot [ERROR] update_firmware: Failed to back up current firmware

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #12028
    Rens Kluitmans
    Participant

    Hello,

    The last few days I’ve been using the serial usb connection with success to upload firmware with ymodem.

    Until now…. I get the following error:

    [INFO] Backing up current firmware
    [ERROR] backup_firmware: open failed
    [ERROR] update_firmware: Failed to back up current firmware
    [INFO] bootloader version v0.1.1

    bootloader :>
    bootloader :>
    bootloader :>
    bootloader :> transfer ymodem
    [INFO] Starting YMODEM file transfer
    [ERROR] failed to receive ‘fw_upgrade.bin’
    [ERROR] YMODEM file transfer failed
    bootloader :>

    Anyone had this before? How to solve it and even more important how to avoid this in the future?

    With kind regards,

    Rens

    #12283
    Andrew Wixted
    Participant

    Hi Rens,

    Did you manage to solve this problem?

    I have the identical problem with the same version bootloader.

    I have an MTDOT 868 XIP SMA 1 that some time ago decided that it was a 915Mhz chip.

    I reflashed it via the drag and drop method and via the bootloader

    I flashed a ‘Hello World’ demo (which installed)
    I flashed a deep-sleep demo which worked but the system still thought it a 915MHz device.
    I reflashed a Hello World (which worked)
    I flashed the latest AT firmware but instead of an AT interface it was running the Deep Sleep demo. (the AT firmware loaded on another mDot)
    I repeated the last two steps but it always went back to the deep sleep demo.

    Now when I try and flash I run into the Issue you documented.

    bootloader :> transfer ymodem
    [INFO] Starting YMODEM file transfer
    [ERROR] failed to receive ‘fw_upgrade.bin’
    [ERROR] YMODEM file transfer failed

    Anyone out there know if there is some more information about the bootloader available?

    I now cannot load this mDot via the bootloader or the file system.
    Is performing the bootloader ERASE command an option?

    It seems to me that the ‘deep sleep’ demo was being backed up and somehow being restored for some unknown reason – or remained loaded in a different area and wasn’t overwritten when it should have been.

    regards
    andrew

    #12284
    Andrew Wixted
    Participant

    Okay: just replying to myself so if anyone else has this question here is an answer.

    The bootloader has an erase option with a warning.
    erase: erase entire 2MB external flash – BE SURE YOU WANT TO DO THIS!

    I don’t know what the warning warns against.

    I ran the erase option.

    bootloader :> erase
    Erasing external flash…Done

    I loaded the AT firmware file via the development board (dropping the file into the multitech directory).

    This worked.

    I repeated this (Erase) and then did a load via the bootloader and that load also worked.

    Unfortunately for me my original problem still exists (868 mDot thinks it is a 915 mDot)

    #12287
    Mike Fiore
    Blocked

    There are some configuration files the mDot maintains on the filesystem. One of them contains the frequency band the device operates in and the device ID. When you erased the entire flash, your mDot lost its configuration and reverted to defaults (915 frequency band).

    Were you storing any files in the filesystem? It may have been full, which would cause an upgrade/transfer via the bootlaoder to fail.

    Even though upgrading via the bootloader fails, can you still flash via the normal drag-and-drop method?

    -Mike

    #12312
    Andrew Wixted
    Participant

    Hi Mike,

    Prior to the ‘erase’ I couldn’t load via the development board or via the boot loader.

    I had only been using the mDot as an AT command device. When it forgot what freq it was I started fiddling to see if I could restore it to 868 operation. (by trying some of the demo programs). After using the deep sleep demo I couldn’t seem to get rid of it. Loaded the ‘hello world’ demo (it worked), loaded the AT firmware again – but it ran the ‘deep sleep’ demo. Loaded ‘hello world’ demo again (it worked), loaded the AT firmware but it started running the ‘deep sleep’ demo. (Loaded the AT firmware into another device and it upgraded to the latest firmware so it wasn’t a case of loading the wrong binary file.)

    At this point I started playing with the bootloader. Followed pretty much the same process of loading the ‘hello world’ demo and then the AT firmware. Then the bootloader when nuts and I couldn’t load via either method. I did do a bootloader ‘send’ and the file it sent me (fw_backup.bin) looks like the deep sleep demo.

    (1)
    Are there bootloader instructions ?
    For instance, is there a list command so we can read filenames?

    (2)
    More importantly, is there a way to restore this device to 868 operation

    regards
    Andrew

    Example of the Bootloader conversation.
    **********************LOADING A FILE (ALL OK)*****

    bootloader :> upgrade ymodem
    [INFO] Starting upgrade
    [INFO] Starting YMODEM file transfer
    C[INFO] YMODEM file transfer succeeded
    [INFO] appended crc: 4184045605
    [INFO] calculated crc: 4184045605
    [INFO] erasing sector 4 addr 0X8010000
    [INFO] erasing sector 5 addr 0X8020000
    [INFO] erasing sector 6 addr 0X8040000
    [INFO] erasing sector 7 addr 0X8060000
    [INFO] 0X31A0 bytes remaining
    [INFO] 0X11A0 bytes remaining
    [INFO] 0 bytes remaining
    [INFO] Flashing new firmware successful
    <changed port speed to 9600>
    Hello world!
    Hello world!
    Hello world!
    Hello world!
    Hello world!
    Hello world!
    Hello world!
    **********************Next transaction
    I don’t have a capture for this bit but I tried doing the same as above but for the AT firmware
    eg upgrade ymodem.

    On this occasion it gave a crc error (or something similar)
    so I tried an alternative method using ‘transfer’

    **********************TRYING A FILE TRANSFER***************************
    bootloader :> transfer ymodem
    [INFO] Starting YMODEM file transfer
    [ERROR] failed to receive ‘fw_upgrade.bin’
    [ERROR] YMODEM file transfer failed
    bootloader :> transfer ymodem
    [INFO] Starting YMODEM file transfer
    [ERROR] failed to receive ‘fw_upgrade.bin’
    [ERROR] YMODEM file transfer failed

    *************** DELETING A FILE *****************
    I wasn’t trying to send ‘fw_backup.bin’ so i assumed that fw_backup.bin might have been the internal file name for the file I was trying to transfer.
    As an experiment I tried to delete the file fw_backup.bin
    Then I tried to delete a non-existant file.

    bootloader :> delete fw_upgrade.bin
    [ERROR] File ‘fw_upgrade.bin’ could not be deleted
    bootloader :> delete backup.bin
    [ERROR] File ‘backup.bin’ does not exist in filesystem

    ********************* TRIED THE SEND COMMAND *****
    Guessed at a file name to try (using the name that had come up earlier)
    And then it went nuts. (Note I received the file and looking inside it appeared to be the ‘deep sleep’ demo)

    bootloader :> send ymodem fw_upgrade.bin
    [INFO] Starting YMODEM file send ‘fw_upgrade.bin’
    [INFO] YMODEM file send succeeded ‘fw_upgrade.bin’
    bootloader :> [INFO] Backing up current firmware
    [ERROR] backup_firmware: open failed
    [ERROR] update_firmware: Failed to back up current firmware
    [INFO] Backing up current firmware
    [ERROR] backup_firmware: open failed
    [ERROR] update_firmware: Failed to back up current firmware
    [INFO] Backing up current firmware

    ***********************************
    From here on any attempt to transfer a file in either direction failed with crc? errors or 0 bytes sent or in the case of using the file system to drop in a file – the lights on the development board flash as expected but I couldn’t install any file until I ran the erase.

    #12357
    Rens Kluitmans
    Participant

    Hello Andrew,

    After your post to do the erase: erase entire 2MB external flash – BE SURE YOU WANT TO DO THIS! I decided to also give it a try.

    After this I finally was able to load firmware again. Unfortunately, as what was expected, I also lost the frequency and device Id setting.

    Just like Mike explained; When you erased the entire flash, your mDot lost its configuration and reverted to defaults (915 frequency band).

    On the RMA request I already had in place with Multitech I asked the question if I still needed to RMA the unit or if it could be solved by some commands.

    They supplied me with a special binary file mdot-firmware-Set-DevID-868.bin and some commands. After flashing with this, setting the device id and putting back Mike’s AT firmware I was back up and running on my module.

    Need to do some further testing but for now it seems to have solved my issues.

    Regard,

    Rens

    #28204

    Hi
    i have the same prob
    i falsh the mdot and the freq change to 915 but i works in 868 freq
    how did you change the freq plz
    thanks

    #28205
    Jason Reiss
    Keymaster

    The firmware controls the frequencies used. If an EU868 firmware is flashed on to the device then EU868 frequencies are used.

    https://webfiles.multitech.com/wireless/mtdot/dot-v3.2.1/mdot-firmware-3.2.1-EU868-mbed-os-5.11.1.bin

    If the configuration in external flash was erased then the configuration output will show 915 as default. The DevEUI was also lost and a special firmware is needed to restore it.

    Also if a device was originally a 915 device and EU868 firmware is flash the default frequency will continue to report 915.

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