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

[mark]

Neil

By setting the define SPI_FILE_SYSTEM in config.h rather than FLASH_FILE_SYSTEM (either one or the other) the file system and parameter system are located in external SPI EEPROM. See the document http://www.utasker.com/docs/uTasker/uTaskerSPI_EEPROM.pdf

The size of the EEPROM and other parameters are set up in app_hw_xxxx.h.

Presently the device supported is an EEPROM but it is controlled as if it were a FLASH device.
To add the larger FLASH SPI devices to the SPI_FILE_SYSTEM (as Dean has already done) just the driver interface needs to be changed. The size of the chip is not a problem since this just defines how many pages actually exist. A project can set this up for the specific type to be used. A possible configuration for a 1Meg device would be

Code: [Select]

    #define FILE_GRANULARITY (512)                                                // Page size
    #define SINGLE_FILE_SIZE (32*2*FILE_GRANULARITY)                    // each file a multiple of 32k
    #define FILE_SYSTEM_SIZE (32*SINGLE_FILE_SIZE)                       // 32 files (1Meg) reserved for file system (including parameter blocks)
If more than 1 FLASH device is used the driver would in addition need to know the size of each in order to set the correct CS line. Presently the code only supports one chip but this is of course only a detail as long as the second CS is physically available.

The QSPI is specific to the M5223X but until now I haven't found any advantage in using the CS lines dedicated to the QSPI for such control. It takes much more code to control them from the QSPI hardware than as GPIOs.

Since I have the 45DB041 code ready in my project (configurable for 021..161) I think that I can adapt the boot loader if you need it. Say from mid. August 2007. It is certainly possible to also share it with other things, the only complication is ensuring a generic solution. This would be a second step.

I have a question for you, since you know the 45DB081 well:

The SPI FLASH has page sizes of either 264 or 256 bytes. Default is 264. Therefore the part actually has 32k more that its 1Meg if used in 264 byte mode(?).
Once the device is set to 254 byte page size it can not be switched back.
254 byte page sizes are easier to work with (SW is more efficient since it can use power of 2 multiplication and divides when calculating addresses of pages etc.). How do you use it? I am still wondering on how best to set it up, although I still have 264 bytes pages at the moment. What strategy should I go for??

Regards

Mark

[neil]

Hi Mark,
  Mid august will be fine for me, as I can design the board around this.

  The device has 4096 pages with 264bytes/page, giving it a total of 1081344 bytes. I think the layout is the same as the smaller part, but with more pages (not sure though). Heres a link to the datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc2225.pdf

At present I simply save data results from page 100 to 4095, below 100 for applicaiton setup. I have a 264 bytes buffer in my processor, and fill this up. When time to save, I simply save the whole page, which is a lot quicker than saving byte per byte. Its a bit more tricker when the data overlaps the page boundry. This is where I then load the next page, and patch in the rest of the data to save. I have a structure which deals with the position with the memory. As you can see, its nothing fancy, but this way I can save a lot of data there, with ease. My application only saves data, and not seperate files, so no need for FAT tables etc.

Neil

[neil]

Hi Mark,
  When a firmware updated is needed, my own code has to save the new firmware (will be either from ethernet, or GPRS (serial)) onto external memory (this is the way we want to go), and do we simply reset the processor, then the bootloader will come into play?

How does the bootloader know where the file is? We will have 2 external eeproms, one for firmware, and one for our own data. As we will be using the 1MB (actually a bit larger), we would like to use the rest of the chip for our own data, would this be a problem?

We save data on the flash every minute, and because  there is a maximum writes per page we have to be carefull of not using same pages too often (as the page gets cleared when data is sent to our server), so we never reset the save pointer, always increase , then loop to start again. Do you do the same?

Is there anyway we can use data card, that holds 16MB etc too?

You mention that you do not use the 52235 own spi chip select, but an IO, but you use the SPI interface (and not IO lines for communication)?

Regards
Neil

[mark]

Neil
The boot loader always does a check to see whether there is new code waiting to be loaded (it checks the file format, a magic number and then a CRC-16 over the file length). This means that if your applcation loads it to the correct place (also a parameter in the bootloader) all it has to do is command a reset and this will kick off the process.

The boot loader has to be set up to know where the file is (there are a number of defines in the code and these must match the application and also the converter - eg. to ensure correct magic numbers and an any signatures which ensure that only matching code is recognised and loaded).

I don't expect and problems with mixing the use of the devices. The file has a certain length and the rest will be ignored.
I am aware of the restictions on write cycles but I don't think that this will be an issue regarding boot loader. Rather it is an issue for application use. The Atmel chip that I am using speciies at least one complete erase every 10'000 writes. The final solution is still open at my end...

At the momnet I haven't look at larger data cards so I can't comment on these.

I use the QSPI on the M5223X (CLK, MISO, MOSI) It is only the CS line which I control as GPIO rather than allowing the QSPI to do it itself. I just don't see any reasons to do it any differently - the code size to set it up is much greater than just toggling the port in this use.

Regards

Mark