µTasker Forum > µTasker general
Boot Loader
neil:
Hi,
We have a new project coming up, and hopefully be using the utasker (just downloaded the utasker for the first time a few weeks ago, and testing it out).
We will have many units throughout the world, and some will be in remote areas where getting to will take hours, so we are thinking of having the ability to re-programm the firmware remotely.
I have a couple of questions regarding this feature in uTasker.
1. In our system there are 2 options the way the user can use our product, either by GPRS, or ethernet(if there is a connection). If the connection is GPRS (to our M52233), can we still use the boot feature? Or can we modify the code to do so?
2. what would happen in the following scenario: A connection is made, the firmware is being updated and the connection is lost half way through. Would the processor restart, and we can reconnect and restart upload procedure again?
Many Thanks
Neil
mark:
Hi Neil
1. The project includes all routines necessary to do updates in various ways. The demo project allows for example uploading new code using FTP or by using HTTP post. If you have a GPSR connection it is probably connected via UART and so a routine to store the new code received via UART to the same file can be added (there is not one in the present project but this is not difficult to add).
As long as the loaded file has the correct format and is at the correct location it will be compatible with the "Bare-Minimum" Boot loader and so how it is actually loaded (whether via EThernet or another interface) makes no real difference.
2. The "Bare-Minimum" Boot loader is presently supported by the M5223X and SAM7X projects. It occupies about 2k of memory. Get full detail from:
http://www.utasker.com/docs/uTasker/uTaskerBootLoader.PDF
http://www.utasker.com/docs/uTasker/BM-Booloader_for_SAM7X.PDF
http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF
If a file upload is unsuccessful it doesn't affect the normal operation of the application and so can be repeated at a later time. The processor resets only once the upload is complete (although exactly how it responds can be defined by the application).
After a reset, the procedure ensures that a power loss can not cause the device to be left without either the original application or the new one intack. The only thing that could go wrong is when the user actually loads a new application which is non-operational. It is in the user's responsibility to ensure that only tested software is converted to the correct format and loaded to remote devices!!
Regards
Mark
neil:
Hi mark,
Thanks for the reply. It sounds perfect for our needs. One thing, is it possible to have the downloaded code stored in an external flash, rather than internal flash? This way we can use more space for our code (as it will grow in time).
Neil
mark:
Hi Neil
As you have noticed, the boot loader technique - due to its requirement for fail safe uploads - requires the old and new code to both be present in FLASH at the same time. This does require that the available FLASH can handle this or puts more of a limit on the maximum program size.
Often it is possible to use the existing file system to temporarily store the new code, however overwriting and files there. Afterwards the overwritten files can be re-loaded - via FTP for example. This can often optimise the amount of FLASH to enable what is required.
Of course there is always some limit and the next step will be to allow the new code to be stored in inexpensive off-chip FLASH. See the topic about the external EEPROM alternative: http://www.utasker.com/forum/index.php?topic=4.0
Presently I am implementing this for the Atmel part (512K) and Dean has already something running on the ST part (note that ST has two parts - one is a data flash and one is a program FLASH. Dean has used the data FLASH because it is well suited to a file system with fine FLASH granularity. If only software uploads are to be performed the program FLASH part would also be suitable).
In the application there are three choices:
1. Have the file system completely in external SPI FLASH (maximised code space and Dean has it working)
2. Have the file system in internel FLASH and a software upoad in external SPI FLASH (this is what my first project is doing).
3. Have files in both internal FLASH and external SPI (file location can be defined to be in either) but SW uploads will be external due to space. (this is a bit more complicated and needs still to be solved at the FS level).
1 and 2 are basically working and make most sense for SW uploads.
What then needs to be done is to add the new driver code to the "Bare-Minimum" boot software - it is not much more code since the driver is basically some extra SPI routines. I expect that it will still fit in 2k.
Therefore my conclusion is that it is an important addition to the present concept which will allow more SW size flexibility with only small HW cost increase (one-off price for the SPI FLASH is about $3 for my ATMEL 512K part and in quantity they are certainly good value).
If you need it, I think there is no problem to recon on it being available in the short term. If it is not ready when you need it, available code and support should allow you to integrate it with quite small effort.
Regards
Mark
neil:
Hi mark,
excellent, at present I am using the atmel part 45DB081D (1MB) which is an excellent part. I havent designed the board yet, waiting till I fully test utasker (which so far is excellent). But if the bootloader will soon be available for this part then that would be great. Do you recon this feature will be available soon?
My application will be using the 45DB081D (as well as another one for bootloader ;) ) , can I use the file system on this one too? If I also have 2 , I assume it will be a matter of selecting which qspi chip select to use on which device, as there are 4 available?
If I use the 45DB081D for bootloader too (its cheap, and as I have many of these, dont want to purchase smaller versions), I assume that I can use the free space for other things too, like program setup etc?
Thanks again
Neil
Navigation
[0] Message Index
[#] Next page
Go to full version