Author Topic: file system and bootloader  (Read 14004 times)

Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
file system and bootloader
« on: January 12, 2009, 01:03:07 PM »
Hi Mark,
  I have a system with 1 external spi memory chip (AT45DB081B). I plan to use the first 256k for bootloader, the next 2 pages(or maybe  a bit more) for my use, and the rest for uFilesystem. 

I have tested the spi bootloader, and spi uFilesystem (but not at the same time), and works great. But not sure what to set so I can use the memory as above.

Also,what happens to the parameter block in this case?  I would like to have the parameter block in spi memory. Looking at the document, this is at the start of the spi memory block, so will this be after the bootloader space, and the 2 pages I want to set aside.

Im using the 256k memory freescale parts, could you let me know what, and values to set to get the above to work?

Regards
Neil



Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #1 on: January 12, 2009, 01:58:14 PM »
Hi Neil

In the latest SPs the parameter system and file system can be defined separately so this can be positioned either in the internal or external FLASH, so is flexible.

When using the file system in, and performing uploads to, the SPI FLASH, the preferred solution is to put the upload space to the very end of the file system. It is (presently) not possible to defined the upload space to be outside of the file system (I did look into this for someone else before and it could of course be made possible but requires a change in uFile.c to control it - we decided that there is actually no (known) advantage of making this possible since it is purely a convention as to exactly where it is in SPI FLASH).

The suggested solution is therefore.
- parameter system at the start of SPI FLASH
-some space for low level access outside of the file system
- uFileSystem
- last file in file system (can be as large as the remaining FLASH physical size, or less depending on uFileSystem size definition) used for firmware uploads

This should not require any special solution and should be very easy to set up. The boot loader needs to be configured for SPI_SW_UPLOAD and the address equal to the file address where the upload takes place.

Regards

Mark

Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
Re: file system and bootloader
« Reply #2 on: January 12, 2009, 02:13:15 PM »
Hi Mark,
  Thanks for the above.

I am not using the SP with the built in USB feature,as I am not using this chip, but have the SP before this.

1. How do I find the last address in the file system to enter into the boatloader application?

2.How do  I set the last file in the file system to use the remaining memory available?

3.Is there a way to know what the page number is at the start of the memory for firmware upload?

Regards
Neil
« Last Edit: January 12, 2009, 02:51:14 PM by neil »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #3 on: January 12, 2009, 03:32:12 PM »
Neil

The new parameter PARAMETER_BLOCK_START is not in SP7 but the changes are not that big so maybe you could integrate these. Alternatively you could move to SP8 (in any case use the reference config.h for SP8 as reference as to the adjustments).
If you stay with SP7 the only difference is that you need to keep the parameters and the uFileSystem contiguous in SPI FLASH so you can put your own low level access pages before the parameters, rather than between them and the file system.

- some space for low level access outside of the file system
- parameter system at the start of SPI FLASH
- uFileSystem
- last file in file system (can be as large as the remaining FLASH physical size, or less depending on uFileSystem size definition) used for firmware uploads

1. How do I find the last address in the file system to enter into the boot loader application?
2. How do  I set the last file in the file system to use the remaining memory available?
3. Is there a way to know what the page number is at the start of the memory for firmware upload?
These all depend on the chip, the start of the parameters (file system starts just after the end of parameters in SP7), the size of parameters, the size of file granularity, the size of file granularity and defined size of file system. But of course all addresses can quite easily be calculated, as can the corresponding page number of any location.

I suggest using the following document as reference (it is for internal FLASH so be careful that your ATLMEL has 264 byte pages and not 256 byte - this makes the addresses a little strange):
\Applications\uTaskerV1.3\WebPages\WebPagesM5223X\FileSystem\FileSystemM5223X_160k.doc
(best take the reference from the SP8 since it has a couple of corrections in it!!).

In the table you will see that the file system names finish at 'z'. If the file system space is larger than (62 x file granularity) [62 is the maximum number of individual files for file granularity size] the last file 'z' occupies from this location - (file system start + 62 x file granularity) and can be as large as the remaining memory space.
File system start will, in your case be equal to the offset to the start of parameters (defined by the size of your memory space at the beginning) plus the parameter block size (usually twice the parameter size due to swap-block).
The virtual start of SPI FLASH is after the end of the internal FLASH (256k in your case). The page in the SPI FLASH is then simply the offset into SPI FLASH divided by the page size.

It is worth doing the exercise once since then you will know exactly where all data is physically located and any adjustment that you may want to make later will be easier to do.

Regards

Mark



Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
Re: file system and bootloader
« Reply #4 on: January 12, 2009, 10:41:46 PM »
Hi Mark
  I am going to upgrade to SP8, but as I now have my project setup with my own files added, can I simply replace the files effected?

Regards
Neil

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #5 on: January 12, 2009, 11:12:33 PM »
Neil

I would make a copy of the project to start with. Then add SP8, which will overwrite the changed files.
If you haven't modified any files outside of the application directory (recommended) you can concentrate on the content of this directory.

Your config.h will not be overwritten but you may need to add new defines from the reference config_xxx_spx.h to activate new features and also due to the new parameter position (use the file as reference). Also check through the service pack release notes - this will give you details and some tips, and you can also get an idea of new features which you may then find use for.

Any files that you have added will not be modified - you may however need to add them to the CW project (if it is updated), or else use your original one again. If you modified application.h or application.h etc. you may need to copy yours back again since they will be overwritten. Just check the header to see what was changed since the changes are mainly new demos which you don't need anyway.

Finally check the SP thread for patches etc.: http://www.utasker.com/forum/index.php?topic=352.0

It shouldn't be very difficult and I think that it is generally worth while (when not right in the middle of a project) to update to be sure of newest features and and corrections.

Regards

Mark

Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
Re: file system and bootloader
« Reply #6 on: January 13, 2009, 10:43:55 AM »
Hi Mark,
   During compiling I get the error:

identifier 'size_t' redeclared
was : 'unsigned int'
now : 'unsigned long'


size_t.h file:

     #ifndef _MSL_SIZE_T_DEFINED
      #define _MSL_SIZE_T_DEFINED
      typedef _MSL_SIZE_T_TYPE size_t;    <<<< error here
   #endif

Neil

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #7 on: January 13, 2009, 11:26:26 AM »
Neil

I presume that the size_t.h is being included from one of your own C-files. (Perhaps over other headers)
In this case you can remove the typedef for size_t in types.h

Make sure that you include your headers in config.h (or types.h) so that they are also valid for uTasker C-files, otherwise the size_t will be missing there.

I don't know why this should be a problem in SP8 but not SP7 - perhaps you already did a similar change before, which has been overwritten and needs modifying again(?).


Regards

Mark

Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
Re: file system and bootloader
« Reply #8 on: January 13, 2009, 12:20:03 PM »
Hi Mark,
  That worked fine, thanks.

A couple of questions (im using atmel part for firmware upload and file system):

1.. if the PARAMETER_BLOCK_START is set to the last 2 blocks in Flash Memory, will this area get erased by the bootloader while updating the firmware? If so I will have to place it in SPI memory.

2..I have a routine that uploads the firmware to the spi memory, and works fine. At the moment I dont use the file system to do this, I simply save by page number. Can I therefore not:

a..Set PARAMETER_BLOCK_START right after the first 256k space (if 1. above doesnt get erased, then this will be in flash memory), then right after this set uFILE_START after this.

I would have either:
#define PARAMETER_BLOCK_START 0x82000  //in spi memory after 256k , and space for my own info.
#define uFILE_START 0x83000 

or
#define PARAMETER_BLOCK_START 0x3f000  //in flash memory
#define uFILE_START 0x82000  // after 256k , and space for my own info.

I will also have to adjust the size of memory left for the file system

Regards
Neil

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #9 on: January 13, 2009, 01:25:56 PM »
Hi Neil

1.. if the PARAMETER_BLOCK_START is set to the last 2 blocks in Flash Memory, will this area get erased by the bootloader while updating the firmware? If so I will have to place it in SPI memory.

As long as the program is not so large that it also overlaps with the last 2 FLASH blocks this is the recommended solution.

2..

I will have to study this later and will get back. (Must travel for a couple of hours)



Regards

Mark

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #10 on: January 14, 2009, 02:34:35 AM »
Neil

I suggest something like the following:

#define PARAMETER_BLOCK_START 0x3f000  //in flash memory
#define uFILE_START 0x44200  // after 256k , and space for my own info. (~16k (16896) bytes) - remember the page size if 264 bytes (not 256)
#define SPI_FLASH_BLOCK_LENGTH (8*SPI_FLASH_PAGE_LENGTH)      // 2112 bytes
#define FILE_GRANULARITY (8*SPI_FLASH_BLOCK_LENGTH)                  // ~16k (16896)
#define SINGLE_FILE_SIZE (FILE_GRANULARITY)
#define FILE_SYSTEM_SIZE (63*SINGLE_FILE_SIZE)                              // ~ 1Meg (106448 bytes)

The file system will hold up to 63 individual files of 16k (or less when some occupy more than one file block).

In order to update SW of up to 256k, the file 'm' is about right (it may be an idea to generate an Excel table to see the exact file addresses)
This file location can accept 256k of content (up to around the end of the SPI FLASH).

You can use any routine to write the upload content but you will need to ensure that it has the uFileSystem header set at the beginning so the boot loader understands that it is a file (http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF)

Note that the uTasker simulator comes in handy when playing around with such configurations. It allows the position FLASH contents (internal and external) to be checked so that you are sure that the data is correctly copied to where you are expecting..


Regards

Mark


Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
Re: file system and bootloader
« Reply #11 on: January 14, 2009, 11:02:41 AM »
Hi Mark,
 
>>The file system will hold up to 63 individual files of 16k (or less when some occupy more than one file block).

This is before the defines are modified to above values (as 63 x 16k=1,048,576 bytes)?


>>In order to update SW of up to 256k, the file 'm' is about right (it may be an idea to generate an Excel table to see the exact file addresses)
This file location can accept 256k of content (up to around the end of the SPI FLASH).

Do you mean after the file system setup above (the defines), the file system will go up to 'm' (approx, I will calc in excel), the first after my 16k for my own info?

Regards
Neil

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: file system and bootloader
« Reply #12 on: January 14, 2009, 02:12:59 PM »
Neil

All values without guaranty, but remember that the 1Meg ATMEL part has 264 byte pages and not 256 byte, therefore it has, in total 1'081'344 bytes (1.056M) in total and not 1Meg (1'048'578)

File '0' begins after some space reserved for other use. 'm' is the start of the upload space. The file system does in fact go up to 'z' but nothing in this range should be used for normal file otherwise it will get overwritten during upload use. It is of course possible to share the space and reload any lost files after an upload but, if there is enough memory available, separate areas are simpler.

Regards

Mark