FOTA-BGS5 | Thales IoT Developer Community
December 21, 2017 - 8:54am, 3625 views
Hello,
I want to update firmware of a BGS5 module by using usf and jrc midlet files.
What is the procedure of that?
I have copied jrc files and usf file to module ffs by using MES. Then I have sent at^sfdl=2 command via usb interface. It didn't work.
Best Regards,
Ergün.
Hello,
The usf file must be named SAM_2130M_FOTA.usf for that to work. JRC MIDlet you install like any other MIDlet. You need to stop and uninstall the previous one before and then install the new one. I'll send you the document with the procedure description. Besides that there's a demo application FotaMIDlet which you should find on your PC: "C:\Users\Public\Cinterion\EHS5 WTK Examples" or it is also in our Knowledge Base.
Best regards,
Bartłomiej
Hi,
check this article that contains the verbose of the FW(usf and JAD/JAR) update over linux
https://iot-developer.thalesgroup.com/tutorial/ehsx-linux-firmware-updat...
The procedure you need to follow is the same, just taking in consideration the name of the usf file in the FFS, as Bartlomiej pointed, and the name of the JAD and JAD, and that the files are transfered with at^sdfl ( no MES in this example)
Please, take in consideration that the JRC only works with his usf file
Regards
ALopez
Somewhere over the rainbow!!! Looking for the Oz Land!!!
Hello Bartlomiej and Alopez, thanks for the answers.
Bartlomiej, I have received and read the Application Note 17 which you sent to my mail.
Alopez, I have also looked at the link you offered.
It is more clear at the moment.
I want to state that AT^SFDL command made me confused firstly. Because there are completely 2 different usages of this command.
One is AT^SFDL execute command which starts a usf file transfer from a customer utility program hosting on a PC to module. It is a detailed process and there a lot of points to care. Response codes, timeouts, retries, error codes, etc..
Second is, AT^SFDL=2 command which is less complex compared to one from the developer point of view. It transfers the usf file in module ffs root directory to secret firmware field in the module. Command itself manages usf file partitions, checksums etc..
At the beginning, I didn't notice this difference. Now, I could be able to update module firmware by using at^sfdl=2 command. I copied the usf file into module ffs with MES and renamed it as SAM_2130M_FOTA.usf.
I have one question at the moment. In FOTAMidlet example, in UsfUpdater class, defaultUsfFileName is set to "SAM_6260.usf". Downloaded usf file is renamed as "SAM_6260.usf". Do you know why?
Best Regards,
Hello,
AT^SFDL option is indeed more complicated. It is used by desktop applications to flash the module. As I remember the AT^SFDL=2 option was introduced later. And at that time the module's built-in flash file system was too small for the firmware file and the external flash was needed to be connected over SPI.
For fimware update over the air AT^SFDL=2 is much easier and more reliable as all the update logic is done inside the module.
"SAM_6260.usf" name was used for EHS6 module.
Regards,
Bartłomiej
Hello Bartlomiej,
Thank you for the explanation.
Yes, you are right. AT^SFDL=2 way is easier. Module makes all the work inside itself. And actually I only need it, not AT^SFDL. Because I need to update module firmware remotely. For this purpose, I will download the usf file into module ffs and execute AT^SFDL=2.
For update from PC, I can use gwinswup exe which uses AT^SFDL in its logic. No need to develope a new desktop app.
"SAM_6260.usf" is for EHS6. Ok.
Best Regards,
Ergün.