Bootloader and Flash segments

[Stan]

Hello,

I work with SAM7X256 and I've made some changes in the uTasker's code because I wanted to use custom web pages with custom parameters. This is what I did:

1) I inserted my array of parameters in struct stPARS (application.h)

2) I increased PARAMETER_BLOCK_SIZE from 2*FLASH_GRANULARITY(1k) to 14*FLASH_GRANULARITY(7k) as I need more space for the parameters (app_hw_sam7x.h)

3) I changed UPLOAD_FILE_LOCATION from 0x127800 to 0x129000 (uTaskerBootLoader.c in Bootloader's project) - I increase this address with 6kbyte as I increase parameter block size with 6kbyte

Do I have to make more changes in order to work everything properly? Now I upload z_Upload.bin file, reboot and when uTasker is loaded I see that it deletes the bin file for the ftp but software remains the same, the newer version is not loaded.


There are few things to mention:

1) In uTasker's Documents it is said that the files in the file system are in the following order: 0...9a...zA...Z
but in the source code they are 0...9A...Za...z like in ASCII.

2) I don't think that it's good idea UPLOAD_FILE_LOCATION to be constant number.

3) From what I see the FLASH memory is divided in the following order(originally):

0x100 000 - FLASH start

0x100 000 to 0x100 6FF - Bootloader

0x100 700 to 0x117 FFF - Application

0x118 000 to 0x118 400 - Parameters (0x400 = 1024 = 1k which is by default)

0x118 401 to 0x127 7FF - File System

0x127 800 to 0x140 000 - Space for uploading new software (0x127 800 is the address on which file starting with 'z' is placed)

0x140 000 - FLASH end

Am I right?

4) Where ucKey[] = {0xa7, 0x48, 0xb6, 0x53, 0x11, 0x24} is placed in the bin file?

5) When I open z_Upload.bin with HEX editor I see:
00 00 B3 61 12 34 ... at the start of the file. What 0000 and B361 are for?

When I upload this file to the FTP and read the SAM7X memory from the CrossStudio I see:

69 B3 00 00 05 00 00 B3 61 12 34 ...

Do you know what happens?


Thanks in advance!

[mark]

Hi Stan

Be careful with the parameter block. If you are using a swap buffer (USE_PAR_SWAP_BLOCK) there will be 2 x the parameter block size. If you increase the parameter block content by 6k it will need 2 x 6k space! This would give 0x12a800 as start of the file system (after it). If your size of 7k is to fit 2 x 3.5k your addresses are of course correct.

Note also that the location 'z' will have a maximum size defined by its address to the end of the defined file system (97k in the demo project). Increasing the parameter part will reduce the maximum upload size, unless its position is moved down to compensate (eg. to 't')...

>>0...9A...Za...z like in ASCII:
If you download the newest versions of the documents from http://www.utasker.com/docs/documentation.html you should find that these have been corrected.

I don't think that it's good idea UPLOAD_FILE_LOCATION to be constant number
The location must match between the application project and the bootloader project. If you take the value from the application project (by including a header file from the application) it will avoid a fixed definition. However it is always necessary to carefully decide where this location is - so this decision part will still be necessary.

>>0x118 000 to 0x118 3ff - Parameters (0x400 = 1024 = 1k which is by default)
>>0x118 400 to 0x127 7FF - File System
You can also see the file system layout in the document \Applications\uTaskerV1.3\WebPages\WebPagesSAM7X\FileSystem\FileSystemSAM7X_160k.doc
The details you give are correct.

>>4) Where ucKey[] = {0xa7, 0x48, 0xb6, 0x53, 0x11, 0x24} is placed in the bin file?

This key is not placed in the bin file. It is used as additional secret input to the check sum of the binary file. The check sum of the binary file is only correct when the same key is pass through the algorithm. This makes it necessary to use the same key to achieve the same check sum - resulting in a simple integrity check of the code (against tampering or unautherised source).

>>00 00 B3 61 12 34 ... at the start of the file. What 0000 and B361 are for?
0000b361 is the length of the software (big endian).
See the header definition:
typedef struct stUPLOAD_HEADER
{
    unsigned long  ulCodeLength;
    unsigned short usMagicNumber;
    unsigned short usCRC;
#ifdef _ENCRYPTED
    unsigned short usRAWCRC;
#endif
} UPLOAD_HEADER;

>>69 B3 00 00 05 00 00 B3 61 12 34 ...
0000b369 is the length of the 'file' (little endian) in which the data and its header are stored.
0x05 is the MINE type of the file (binary) - the rest is the start of the header as above.
This file header corresponds to the uFileSystem definition: http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF
The file header was added when the file was saved by FTP or HTTP post. The boot loader first checks the file header and then reads the content.

Regards

Mark

[Stan]

Hi Mark,

Thank you for the quick reply! Everything is working now. You were right I use 3,5K for parameters with SWAP which makes total of 7K in flash. How should I calculate the checksum (ucKey[]) if I want to change this 1234 (VALID_VERSION_MAGIC_NUMBER)?

Thanks.

[mark]

Stan

You can use any value of ucKey[] and also increase its length.
You need only to use the same value in the boot loader code as used to generate the binary file in its the bat file.
The value VALID_VERSION_MAGIC_NUMBER is a very simple check (visible to the user rather than the invisible ucKey[]) and can be used to simply ensure that incompatible versions of the boot loader and the application are used together. If you have several different projects which shouldn't be loaded to the wrong version of the boot loader this value can be used to manage this.

Regards

Mark

[Stan]

Hi Mark,

Thank you for your explanation. I understand now :]