we have developed our product and we are going to build it now in batches of 100pieces. We have added an auto update feature to it and that works fine.
But now for my question. To enable the auto update feature you need to do some steps. Like it shows in the manual. You first need to enable it and the ram will then be splitt into 2 pieces. Then you need to deploy a special update program to 1 of the partitions. It toke some figuring out, but that works fine now. But do i really need to do it to each of the 100 devices eacht time? I guess the enabeling so, but can’t we copy the entire ram at once? So the application part and the boatloader/update part?
You can do some automation program that uses XModem and MFDeploy to do everything from deploying the firmware to different managed apps. For example, see the EMX updater. It just uses XModem code to download TinyBooter and MFDeploy APIs to deploy firmware/applications.
This is not bad actually, you can even automate updating network settings, SSL seeds…etc
Another idea is to make update process easier is make some adjustments to the managed boot loader app. For example:
if( non formatted mode)
Enable Boot Loader();
else if(firmware mode)
access boot loader mode();
else // boot loader mode
// boot loader app here
// boot loader will load the firmware
On a non-formtted EMX (bootloader is not enabled), you have to deploy this 3 times. It is easier because you are using the same program.
First time, the region is split.
Second time you access boot loader mode.
Third time the boot loader code will run.
Now the bootloader will actually load the main application from an SD card or a network.
can i find any info anywhere on what we can update through the xmodem protocol? Is see that there are some sample program’s on the wiki about using the xmodem protocol. But i can’t seem to be able to download the source to check it. Well i found 1 for fez devices, but that one doesn’t support the 1K check that is needed for an emx based device.
If you need to update TinyBooter, normally, you do that using Teraterm and XModem.
Instead of using Teraterm, you use your own XModem code in a custom application. There are sources online and see this:
ok i found checked them out and i will need to adapt them then. Because an emx uses the 1k check and that isn’t supported on this source.
But that doesn’t provide a sollution for the auto updating part does it? Or am i misunderstanding you? Do you mean deploy a program with through xmodem 3 times using the sample sollution you provided earlier in this thread? And then we have got our bootloader in place. And then upload the actual program?
sorry if i am asking a lot :-[, but we are building the batches in 100pcs at the end of next month (and around a 1000 per year). So i need to find / create a way that is workable for the ladies that are going to do the testing an installing overhere.
I may have given more confusion this way.
Normally, you would go through MFDeploy then deploy your application(s).
My idea is to make a PC program that can automate the steps and deploy any programs on the FEZ Cobra using MFDeploy dlls. You have more flexibility this way.
You can deploy an initial program to change to boot loader mode. Then deploy another program which can be the application…etc
Goodmorning Mike (as it is morning in the Netherlands ),
ok i understand it, i was already creating something like that. It is almost finished. I only need to find some info on how to do the 1k check. Alle the samples i have found until now use the other two types.
Updaters are now part of the SDK distributions. You will find it on your disk.
@ Per Cramer - Hi, we are in a similar situation with mass production for for an application that in IN-FIELD upgrade capable. Would you be willing to share the code used for deploying code on to newly shipped devices.
@ Мike - Just be carefull when usign the same applciation to split the firmware and to run as the main application, just because they are the same applicaiton does not mean it can be the same HEX deployment file. i.e. you cannot burn an HEX file that was generated from a non formatted flash to a formatted flash section, there needs to be a seperate HEX file for the non-formatted and formatted version.
check out pyxis source code it had all you need:
also do a search in the forum you should fine a lots of information in this regard.