Author Topic: Bootload problem  (Read 7583 times)

Offline kaflick

  • Newbie
  • *
  • Posts: 20
    • View Profile
Bootload problem
« on: May 29, 2012, 08:26:11 PM »
I am trying to get the bootloader working with my application and the bootloader location is apparently different from where the application puts the new code.  I am using the spi flash for the download and I am downloading the file over ftp (using the HS.bin name).  The download seems to work fine, it does not show up in the on-chip filesystem but when I get the file from ftp it compares exactly to what I sent.  When the bootloader reads the header all of the values are wrong so I assume that it is reading in the wrong place.  Where is the write done in the application so I can look at the values there and compare with the bootloader?

If you have a writeup on the values used for the locations please direct me to that too.

Thank you,
Keith A Flick

Offline kaflick

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Bootload problem
« Reply #1 on: May 29, 2012, 08:36:56 PM »
It looks like the bootloader is reading from 0x80005 for the header.

Is that where it should be reading from?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Bootload problem
« Reply #2 on: May 29, 2012, 10:28:23 PM »
Hi Keith

If you are uploading by FTP you have to make sure that the file name causes it to load to the correct location (HS.bin would cause it to be stored at the 'H' location accoring to the uFileSystem layout).

The layout of the boot loader depends on the processor used and also on the file system settings. It is necessary to know where the file is written to by the application so that the boot loader can also be adapted to suit - this is more complicated when using SPI Flash because its memory mapping is 'virtual' and so content can not so easily be read using a debugger.

The following guide to solving problems with the boot loader is useful if you can run the simulator: http://www.utasker.com/forum/index.php?topic=902.0

Regards

Mark

Offline kaflick

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Bootload problem
« Reply #3 on: May 30, 2012, 01:04:01 AM »
We are using both the on chip file system and the off chip file system.  Our parameter and configuration files are stored on the on chip file system.  They are large and complicated file that are generated by special configuration programs written for our sales people.  These are then loaded by ftp.  Our program is so large that it has to be written into the spi flash.  I believe that with ftp the special case file HS.bin is stored on the spi flash to be used for the new program.  Is that the only file name that is store on the spi flash?  Can I use another file name that locates it at the beginning of the spi flash?
Or do I need to calculate the offset for the H file and add it to the offset the bootloader uses to locate the header?
I do not have a setup for the simulator and we are not using the web server or your parameter functions since everything has to happen over ftp.

Thank you for your help
Keith A Flick

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Bootload problem
« Reply #4 on: May 30, 2012, 10:10:45 PM »
Hi Keith

I would do the following (it is maybe not very scientific but should work out the details quickly):

1) Add code that does the following:

MEMORY_RANGE_POINTER file_pointer[64];
CHAR cFile = '0';
for (x = 0; x < 64; x++) {
    file_pointer
  • = uFileOpen(&cFile);

    if (cFile == '9') {
        cFile == 'A';
    }
    else if (cFile == 'Z') {
        cFile == 'a';
    }
    else {
        cFile++;
    }
}


2) After this has been run (eg. in some existing initialisation code) either look at the content of the file_pointer array with the debugger or else print it out to the debug interface.

3) From the values you can quickly see where each file is located and also verify the file granularity. If some pointer values toward the end stop incrementing it means that the end of the file system area has been hit.

4) You should get one at 0x80000 (which the boot loader seems to be configured to use) so you can see the file name that the file needs.

Furthermore you can verify that the upload location is optimal for your use (often it is best to reserve just enough space toward the end of the area to accept the largest code upload  and then set the boot loader to match).

Regards

Mark