New firmware release v1.17.0.b1 (Completely new LTE class)


  • administrators

    @danielm I would not allow this in a general release.

    Since you are using custom firmware, you can define the erase yourself in the script file. See below example from the LoPy archive:

    [
        ["e", "0x1000",      "0x40000"],
        ["e", "0x41000",     "0x40000"],
        ["e", "0x81000",     "0x40000"],
        ["e", "0xC1000",     "0x40000"],
        ["e", "0x101000",    "0x40000"],
        ["e", "0x141000",    "0x40000"],
        ["e", "0x181000",    "0x40000"],
        ["e", "0x1C1000",    "0x40000"],
        ["w", "0x1000", "bootloader.bin"],
        ["w", "0x8000", "partitions.bin"],
        ["w", "0x10000", "lopy.bin"]
    ]
    

    All lines starting with "e" are erase commands. Then you have the start block and the erase size (which is limited to 0x40000).

    Please keep in mind that if you use a LoRa or Sigfox device then the LoRa MAC address and Sigfox credentials are stored in the config block (0x3FF000) and if you don't have an online connection while flashing, these details would not be restored. If a device is erased before being flashed for the first time with the online updater, the LoRa MAC address will be permanently lost.

    P.S. Could you please send us an email at support@pycom.io with a reference to this discussion. I have a few ideas that might work really well for you and allow us to get some feedback at the same time.



  • @Xykon
    I currently use esptool.py to perform flash erase mainly because my application checks for a flag in the NVS when booting. If this flag is not present initialization routine is launched during first boot after the upgrade. Secondly I would like to be sure that no data from previous versions will stay in the file system. My application creates config file (during first boot) which may differ between versions of the firmware.



  • @daniel I'm a little bit sad that you did not add a fix to deactivate Ctrl-F if wanted.


  • administrators

    @danielm May I ask what would be the purpose of that? Is it just to erase the flash file system or do you have any reason to erase the config, nvs and ota partitions?



  • @Xykon
    It's great to see option to flash from local file implemented.

    Does it perform full flash erase prior to upgrading? If not, would it be possible to add such option?


  • administrators

    A few notes about the new updater tool:

    It now supports re-setting the default LoRa region stored in flash memory. This is only supported when upgrading the firmware via the online software server.

    It now supports flashing from a local file.

    It also now supports offline mode that allows flashing from a local file when no online connection is available or the software server is unavailable. It is now also possible to "retry" to connect to the software server if the connection has failed. The initial timeout is 5 seconds and will be increased by 5 seconds on every attempt up to a maximum of 60 seconds.

    @seb is working on the documentation for the CLI tool. It has a few new features which you might find helpful.

    First off there are now some helpful messages being displayed by default. For scripting purposes, there is a new global option -q / --quiet to disable the messages.

    One of the new messages being shown is the mode in which the updater is operating. If it shows PIC mode, it is trying to use the Pytrack / Pysense to automatically switch into firmware update mode. If it shows FTDI mode, this indicates an Expansion Board 2.0 (or 3rd party adapter). There are some rare cases where this detection could fail, and you can now force either mode by using the global --ftdi / --pic options. [Update:] These options can now also be used with the update command for the Linux dialog based updater.
    Other notable changes are the sigfox command now functioning correctly and a new option in the lpwan command --erase_region which allows erasing the default LoRa region in flash memory. The other new commands lpwan --lora_region and write_remote are specifically to support the dialog based cli updater for Linux and especially write_remote is not intended for general use.

    As Daniel mentioned this is a mandatory update and you might see various types of error messages in earlier version.

    If you have any issues with this new version please don't hesitate to contact me and I will try to help / fix it as quickly as possible.


Log in to reply
 

Pycom on Twitter