µTasker Forum

µTasker Forum => ATMELTM AT91SAM7X and AVR32 => Topic started by: William on August 13, 2009, 08:05:54 PM

Title: Bootloader----S-REC format file
Post by: William on August 13, 2009, 08:05:54 PM
Hi All,

I just tested the uTaskerSerialBoot (IAR AVR32). It works well with my EVK1100 board. But I can not load my application code. I can not generate the correct S-REC format file by IAR compiler.   What is the PROGRAM_START_OFFSET  ? Is it 0x800000? I am not familiar with S-REC format.  Thanks for your advice.

Title: Re: Bootloader----S-REC format file
Post by: mark on August 13, 2009, 11:03:25 PM
Hi William

First of all I am pleased that the serial loader works on the EVK1100. I assume that this board has an RS232 connector on it.
The reason is that it doesn't work on the EVK1105 board (the one that I have) because it uses a virtual COM port connection via USB. There seems to be a problem with the driver used (probably at the PC side) since it doesn't react to XOFF commands when it is in the process of sending a data file (although it does when it is not actually in the process of sending... strange). The result is that the serial download actually overruns the UART since it has to be stopped for a short time during FLASH programming (every 16k or so).

But back to the question: The application has to be linked at the location defined in the Loader.h file (to match the serial loader configuration).

    #define UTASKER_APP_START         (FLASH_START_ADDRESS + (10*1024))  // application starts at this address

FLASH_START_ADDRESS is 0x80000000 on the UC3A, giving an application link address of 0x80002800

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: William on August 14, 2009, 12:20:26 AM
Hi Mark,

Thanks for your reply.

Where can I set the application link address of  0x80002800? Is it in conf_isp.h file?

#define PROGRAM_START_ADDRESS         (AVR32_FLASH_ADDRESS + PROGRAM_START_OFFSET)

//#define PROGRAM_START_OFFSET          0x00002000 (Original one)

#define PROGRAM_START_OFFSET          0x00002800

I also got an error when I tried to generate the S-REC 19 format file by IAR-Compiler. The error is " Error[e122]: The address 0x80000000 is too large to be represented in the output format 'motorola-s19' "

There is no error if I select "motorola" format file (not S19). But it seems the bootloader does not like it. Any suggestions ? Thanks.

Regards,

William

Title: Re: Bootloader----S-REC format file
Post by: William on August 14, 2009, 12:48:22 AM
It seems that MOTOROLA-S19 uses 16-bit addresses.
Title: Re: Bootloader----S-REC format file
Post by: mark on August 14, 2009, 11:18:06 AM
Hi William

I am a little bit worried that we are not discussing the same thing exactly.

conf_isp.h is not a file in the uTasker project and
#define PROGRAM_START_ADDRESS         (AVR32_FLASH_ADDRESS + PROGRAM_START_OFFSET)
also doesn't exist. These must be in an ATMEL AVR32 loader project (?)

The serial loader in the uTasker project is in the directory \Applications\uTaskerSerialBoot and is configured in the file Loader.h in that directory.

These are the relevant settings:
    #define SERIAL_SPEED              SERIAL_BAUD_115200                 // the Baud rate of the UART
    #define UTASKER_APP_START         (FLASH_START_ADDRESS + (10*1024))  // application starts at this address
    #define UTASKER_APP_END           (unsigned char *)(UTASKER_APP_START + (45*1024))// end of application space - after maximum application size
    #define INTERMEDIATE_PROG_BUFFER  (16*1024)                          // use an intermediate buffer and flow control to avoid character loss during FLASH writes



It may be that you want to load the ATMEL project (as your application). In this case you may need to set the application correspondingly, but that is so that it can do its work correctly and not due to linking. In the IAR project the link address is defined in the linker script file - the reference from the uTasker demo project is in
\Applications\uTaskerV1.4\IAR_AVR32\settings and called lnkuc3a0512_bm.xcl

/************************************************************************/
/*      Reset code is located at address 0x80000000 and up.             */
/************************************************************************/

-Z(CODE)RESET=80000800-8000090f


Here the link address has been set to 0x80000800 for compatibility with the uTasker Ethernet loader (Bare-Minimum loader) but can be set to 0x80002800 to work with the serial loader.

It is true that S19 is not suitable and S28 (motorola-s28 as selected in IAR) needs to be used due the the high address. The uTasker serial loader supports both.

Regards

Mark

Title: Re: Bootloader----S-REC format file
Post by: William on August 14, 2009, 08:35:39 PM
Hi Mark,

Thank you very much for your help.  I am able to generate the s37 format file. The serial loader loaded it successfully. But my application does not run after reboot and it still enters into the Serial Loader mode. I am testing the  ATMEL sample code ..\drivers\USART_EXAMPLE\usart .

I could not find the address 0x80002800 in the Serial loader project.

In the loader.h, I found following:

    #define UTASKER_APP_START         (FLASH_START_ADDRESS + (10*1024))  // application starts at this address
    #define UTASKER_APP_END           (unsigned char *)(UTASKER_APP_START + (45*1024))// end of application space - after maximum application size


In the IAR linker file lnkyc3a0512.xcl,

I replaced  the original address 80000000 with 80002800 in following places.


/************************************************************************/
/*      Reset code is located at address 0x80000000 and up.             */
/************************************************************************/

-Z(CODE)RESET=80002800-8007FFFF


/************************************************************************/
/*      Allocate code and const segments.                               */
/************************************************************************/

-P(CODE)CODE32=80002800-8007FFFF
-P(CONST)DATA32_C=80002800-8007FFFF
-P(CONST)USERDATA32_C=80800000-808001FF

// Initializers
-Z(CONST)INITTAB,DIFUNCT=80002800-8007FFFF
-Z(CONST)CHECKSUM,SWITCH=80002800-8007FFFF
-Z(CONST)DATA21_ID,DATA32_ID=80002800-8007FFFF
-Z(CONST)RAMCODE21_ID,RAMCODE32_ID=80002800-8007FFFF

-Z(CONST)ACTAB,HTAB=80002800-8007FFFF

Title: Re: Bootloader----S-REC format file
Post by: mark on August 14, 2009, 08:45:44 PM
Hi William

The
    #define UTASKER_APP_START         (FLASH_START_ADDRESS + (10*1024))  // application starts at this addr
is the address 0x80002800
Note also that
    #define UTASKER_APP_END           (unsigned char *)(UTASKER_APP_START + (45*1024))// end of application space - after maximum application size
is defining a maximum application size of 45k - if your test application is larger than this you will need to increase it otherwise it will not be accepted.


lnkyc3a0512.xc - make sure that you are changing the one belonging to the application to be loaded any not the serial loader (which must stay at 0x80000000).

If, after a download, the new code is not starting it mean sthat the address 0x80002800 is 0xffffffff (or the force boot input is activated). You can command the application to start using the "go" command: if it then runs it means that the mode is being forced by a hardware input, if it crashes it means that the application hasn't been (fully) loaded. One reason for not fully loading is when the size is too large.

If you have debugging possibilities it is interesting to look at the FLASH content from the address 0x80002800 to see whether it has actually been (partially) written.

Regards

Mark

Title: Re: Bootloader----S-REC format file
Post by: averan on November 10, 2009, 10:49:30 PM
Hi Mark,
    I read this thread and I want to run the Serial Loader from uTasker in a EVK1101 like William declare, but I'dont have success. Reading the forum and documentation I see that you are implement several ports in other evaluation board (like EVK1105), could you please give me some tips in order to configure the Serial Loader for run in the EVK1101 board?


Thanks in advance for your help

Andrés
Title: Re: Bootloader----S-REC format file
Post by: mark on November 11, 2009, 01:50:17 AM
Hi Andrés

Unfortunately I don't have an EVK1101 myself so I can't do any tests, however the first thing to do is to get the serial loader to compile and run on the board.

I believe that the FLASH in the AT32UC3B as on that board is addresses differently to the FLASH in the AT32UC3A0512, on the EVK1105.
Make sure that you change the liner script to link the code to start at 0xa0000000 rather than 0x80000000. Also add a define _AT32UC3B to the project (eg. in app_hw_avr32.h) so that the define FLASH_START_ADDRESS will also match this.

When the loader operates correctly you should have an LED flashing (you may have to configure this to a different port ?) and you should get output on the USART specified in Loader.h (default USART0):

#define LOADER_UART                   0                                  // the serial interface used by the serial loader

Once this is working download attempts can be started.

Regards

Mark

Title: Re: Bootloader----S-REC format file
Post by: mark on November 11, 2009, 06:39:43 PM
Hi All

Since there are a couple of requests about AVR32 downloaders for the UC3B devices (which I haven’t actually used yet but very similar, without Ethernet) I will be ordering EVK1100 and EVK1101 kits to get on top of this.

However I just made a first attempt at changing the USART on the AVR32 UC3A  (EVK1105) – and realised that the USART above USART0 are not being opened due the following setting in app_hw_avr32.h:

    #define NUMBER_SERIAL        1                                       // use USART0 therefore no need for extra ones to be supported

This needs to be incremented to 2 to allow the USART driver to support channel 1 (or higher to support higher channels).

This may be of interest to anyone trying to run any of the kits from a different USART to USART0...

Regards

Mark

Title: Re: Bootloader----S-REC format file
Post by: mark on November 19, 2009, 01:03:39 AM
Hi All

I received an EVK1101 (with AT32UC3B0256) and managed to get the demo project running on it, but I needed to make a few adjustments. The following is a list of the things that I changed - there are a few incompatibilities between the AT32UC3A and AT32UC3B which I didn't expect but they were not difficult to make configurable on the processor type used.


That was more or less what was needed and now there is enough support to configure the serial loader (same setup) and check that loading new firmware works correctly.

Note that the chips are delivered from ATMEL with a pre-installed USB loader. In some cases this can be used as boot loader for your own projects (supports USB and not USARTs) but the code is available from ATMEL and can be configured differently if necessary. Supposedly it uses trampoline routines to allows code to be linked to the normal start location but can also be used with an application linked to other location to avoid these. Full details are in the ATMEL document: http://www.atmel.com/dyn/resources/prod_documents/doc7745.pdf

I don't intend actually using this myself (at the moment) since it is the serial loader which is presently what seems to be demanded but it may well be the best solution in some cases.

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: mark on November 20, 2009, 10:31:53 AM
Hi All

I managed to get the serial loader operating on the EVK1101. It is not 100% because the menu is not understanding the first command entry - one needs to hit return once and then all is OK (it seems there is a spurious character in the input buffer after reset which I need to solve, but not so bad since the download itself is fine).

If anyone with EVK1101 wants to give it a test run already (before fully validated and added to a new project release) try with the attached files:

- uTaskerEVK1101SerialBoot.bin (load to the board with AVR32 studio or whatever method available - linked to 0x80000000)
- uTaskerV1.4.srec this can be downloaded to the board via terminal emulator 115'200 Baud 8 bit, no parity, one stop with XON/XOFF flow control. It is the uTasker demo project with UART menu on the USART1 (the one connected to the DSUB connector - same as used for download).

To force the serial loader mode with the application loaded, reset the board with the push button PB0 held down.

This was compiled with IAR and a GCC project still needs to be created and tested.

Note that the serial loader uses an intermediate buffer since the FLASH can not be programmed on a byte by byte basis with more data arriving by interrupt at 115'200 - with this option it collects a block of data, stops flow by sending XOFF, programs a block and continues by sending an XON to restart the download - full details are in the new version of the serial loader document including AVR32 details in appendix C: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

Regards

Mark

Note: I removed the attachments here due to an update as described in the following post
Title: Re: Bootloader----S-REC format file
Post by: mark on November 20, 2009, 10:34:40 AM
Hi All

Update:
I managed to cure the spurious Rx character on start up (I think that it is generally valid for all AVR32 types, but probably I just didn’t look so closely before). It is necessary to first configure the Rx pins and then enable the Rx module – before, the Rx module was enabled and immediately afterward the pin was configured – supposedly the internal Rx input sees a ‘0’ for a short time which triggers the reception of a character, which is then always 0xff. After changing the order this was solved.

The new attachments (see previous post for details) are corrected.

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: mark on November 21, 2009, 02:29:26 AM
Hi All

Since I also have a new EVK1100 board I have added configurations for it and verified that the serial loader works correctly.
Attached are example files:
- uTaskerEVK1100SerialBoot.bin (serial loader to be programmed to address 0x80000000)
- uTaskerV1.4_EVK1100.srec (example application which can be downloaded)

Note that the serial loader mode can be forced by holding down the user button PB0 at reset.
Both are configured to use USART1 on the board at 115200 Baud 8 bits no parity and XON/XOFF flow control

The example application doesn't use Ethernet, but just a command menu of USART1 and the LED1 blinking on the board.

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: Rambooka on November 24, 2009, 06:00:20 AM
Can you post the serial boot loader BIN files for the EVK1105

Thanks
Ray
Title: Re: Bootloader----S-REC format file
Post by: mark on November 24, 2009, 03:01:22 PM
Hi Ray

The problem with the EVK1105 is that it has a USB interface (for USART0) and there is a problem either with this on the board or else with the driver that it uses on the PC. This doesn't react correctly to XOFF and so doesn't stop sending data when it should. This means that there is a receiver overrun when the FLASH is being programmed.

I have been meaning to add an RS232 converter to another USART so that its operation can be verified on this.

I'll get back after I do this. I will also verify the USB interface again in case there was a mistake the last time, but I was very convinced about it at the time.

Regards

Mark


Title: Re: Bootloader----S-REC format file
Post by: mark on November 24, 2009, 11:15:30 PM
Hi Ray

I can confirm that it really doesn't (unfortunately) work on USART0 due to the USB interface.
On USART1 it works correctly - I added the test files here: http://www.utasker.com/SW_Demos.html

It is necessary to add an RS232 converter to USART1. Also the control of the start-up to either the boot loader or the application (when loaded) is not reliable since it is using the UP KEY - this is a touch key and possibly it needs to be configured correctly, or it is requested too quickly after starting(?) Nevertheless it will allow a download and also testing the new application and would be adjusted to suit the final board in real use.

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: FAQ on December 03, 2009, 11:15:28 PM
When I download my application using the serial loader I get lots of '!' signs.

What does this means any why doesn't it work?
Title: Re: Bootloader----S-REC format file
Post by: mark on December 03, 2009, 11:17:26 PM
Hi

‘!’ means that your SREC is overlapping the serial loader (the serial loader occupies memory from 0x8000000..0x80002800 per default, although this may be slightly different depending on setup). If you link your application to start at 0x8000000 it will try to download to the area occupied by the loader itself. This is not allowed and this sign signals it.

You must therefore ensure that your application is linked to start at 0x80002800 (or whatever is appropriate) so that it can work together with the serial loader

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: brintrup on December 24, 2009, 02:54:17 PM
Hi mark

How I can link my application to start at 0x8000280?

I'm now working with avr32 studio 3.2.

I modified conf_isp.h
#define PROGRAM_START_OFFSET 0x80002800
but not work.

Regards.
Title: Re: Bootloader----S-REC format file
Post by: mark on December 25, 2009, 12:17:23 AM
Hi

I am not sure how the AVR32 studio managed make controls the link address. One idea was that it may be controlled by a linker command line option [Properties -> C/C++ Build -> Settings -> Tool Settings -> AVR32/GNU C Linker -> Miscellaneous -> Linker flags] (possible the -e option?) but I am not sure that that ever worked correctly.

The method that I use is to define my own linker script where this is then easy to do - see uTaskerV1.4_AVR32_BM_2800.ld in the AVR_GNU folder.

The most up-to-date guide to using the uTasker project with AVR32 studio is here:
http://www.utasker.com/forum/index.php?topic=771.0


Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: brintrup on December 28, 2009, 09:55:05 PM
Hi Mark

I made some changes in my own link_uc3b0256.lds script and add some linker flags, but still not working.
With the changes I made in the linker script, my program is not overlapping the bootloader (only shows . during the charge and not appears !). But my application is not working. Finalize the charge of the program and the bootloader write: Starting Application, but the application seems not start. When I press PBO button in my EVK1101 board, appears the bootloader, but when I write go, occurs the same problem.

i'm using the "avr32-objcopy.exe -O srec original.elf final.srec command to convert elf file to srec

Any ideas?

Thanks in advanced.

This is my linker script:

Code: [Select]
/******************************************************************************
 * AVR32 AT32UC3B0256 GNU LD script file.
 *
 * - Compiler:           GNU GCC for AVR32
 * - Supported devices:  AVR32 AT32UC3B0256
 *
 * - author              Atmel Corporation: http://www.atmel.com \n
 *                       Support and FAQ: http://support.atmel.no/
 *
 ******************************************************************************/

/* Copyright (c) 2009 Atmel Corporation. All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 * list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 * this list of conditions and the following disclaimer in the documentation
 * and/or other materials provided with the distribution.
 *
 * 3. The name of Atmel may not be used to endorse or promote products derived
 * from this software without specific prior written permission.
 *
 * 4. This software may only be redistributed and used in connection with an Atmel
 * AVR product.
 *
 * THIS SOFTWARE IS PROVIDED BY ATMEL "AS IS" AND ANY EXPRESS OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE
 * EXPRESSLY AND SPECIFICALLY DISCLAIMED. IN NO EVENT SHALL ATMEL BE LIABLE FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE
 *
 */

OUTPUT_FORMAT("elf32-avr32", "elf32-avr32", "elf32-avr32")

OUTPUT_ARCH(avr32:uc)

ENTRY(_start)

MEMORY
{
  FLASH (rxai!w) : ORIGIN = 0x80002800, LENGTH = 0x00040000
  INTRAM (wxa!ri) : ORIGIN = 0x00000004, LENGTH = 0x00007FFC
  USERPAGE : ORIGIN = 0x80800000, LENGTH = 0x00000200
}

PHDRS
{
  FLASH PT_LOAD;
  INTRAM_ALIGN PT_NULL;
  INTRAM_AT_FLASH PT_LOAD;
  INTRAM PT_NULL;
  FLASH_NVRAM PT_LOAD;
  USERPAGE PT_LOAD;
}

SECTIONS
{
  /* If this heap size is selected, all the INTRAM space from the end of the
     data area to the beginning of the stack will be allocated for the heap. */
  __max_heap_size__ = -1;

  /* Use a default heap size if heap size was not defined. */
  __heap_size__ = DEFINED(__heap_size__) ? __heap_size__ : __max_heap_size__;

  /* Use a default stack size if stack size was not defined. */
  __stack_size__ = DEFINED(__stack_size__) ? __stack_size__ : 4K;

  /* Use a default flash NVRAM size if flash NVRAM size was not defined. */
  __flash_nvram_size__ = DEFINED(__flash_nvram_size__) ? __flash_nvram_size__ : 4K;

  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = 0x80002800); . = 0x80002800;
  .interp         : { *(.interp) } >FLASH AT>FLASH :FLASH
  .reset : {  *(.reset) } >FLASH AT>FLASH :FLASH
  .hash           : { *(.hash) } >FLASH AT>FLASH :FLASH
  .dynsym         : { *(.dynsym) } >FLASH AT>FLASH :FLASH
  .dynstr         : { *(.dynstr) } >FLASH AT>FLASH :FLASH
  .gnu.version    : { *(.gnu.version) } >FLASH AT>FLASH :FLASH
  .gnu.version_d  : { *(.gnu.version_d) } >FLASH AT>FLASH :FLASH
  .gnu.version_r  : { *(.gnu.version_r) } >FLASH AT>FLASH :FLASH
  .rel.init       : { *(.rel.init) } >FLASH AT>FLASH :FLASH
  .rela.init      : { *(.rela.init) } >FLASH AT>FLASH :FLASH
  .rel.text       : { *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) } >FLASH AT>FLASH :FLASH
  .rela.text      : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) } >FLASH AT>FLASH :FLASH
  .rel.fini       : { *(.rel.fini) } >FLASH AT>FLASH :FLASH
  .rela.fini      : { *(.rela.fini) } >FLASH AT>FLASH :FLASH
  .rel.rodata     : { *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) } >FLASH AT>FLASH :FLASH
  .rela.rodata    : { *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) } >FLASH AT>FLASH :FLASH
  .rel.data.rel.ro   : { *(.rel.data.rel.ro*) } >FLASH AT>FLASH :FLASH
  .rela.data.rel.ro   : { *(.rel.data.rel.ro*) } >FLASH AT>FLASH :FLASH
  .rel.data       : { *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) } >FLASH AT>FLASH :FLASH
  .rela.data      : { *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) } >FLASH AT>FLASH :FLASH
  .rel.tdata   : { *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) } >FLASH AT>FLASH :FLASH
  .rela.tdata   : { *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) } >FLASH AT>FLASH :FLASH
  .rel.tbss   : { *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) } >FLASH AT>FLASH :FLASH
  .rela.tbss   : { *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) } >FLASH AT>FLASH :FLASH
  .rel.ctors      : { *(.rel.ctors) } >FLASH AT>FLASH :FLASH
  .rela.ctors     : { *(.rela.ctors) } >FLASH AT>FLASH :FLASH
  .rel.dtors      : { *(.rel.dtors) } >FLASH AT>FLASH :FLASH
  .rela.dtors     : { *(.rela.dtors) } >FLASH AT>FLASH :FLASH
  .rel.got        : { *(.rel.got) } >FLASH AT>FLASH :FLASH
  .rela.got       : { *(.rela.got) } >FLASH AT>FLASH :FLASH
  .rel.bss        : { *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) } >FLASH AT>FLASH :FLASH
  .rela.bss       : { *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) } >FLASH AT>FLASH :FLASH
  .rel.plt        : { *(.rel.plt) } >FLASH AT>FLASH :FLASH
  .rela.plt       : { *(.rela.plt) } >FLASH AT>FLASH :FLASH
  .init           :
  {
    KEEP (*(.init))
  } >FLASH AT>FLASH :FLASH =0xd703d703
  .plt            : { *(.plt) } >FLASH AT>FLASH :FLASH
  .text           :
  {
    *(.text .stub .text.* .gnu.linkonce.t.*)
    KEEP (*(.text.*personality*))
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
  } >FLASH AT>FLASH :FLASH =0xd703d703
  .fini           :
  {
    KEEP (*(.fini))
  } >FLASH AT>FLASH :FLASH =0xd703d703
  PROVIDE (__etext = .);
  PROVIDE (_etext = .);
  PROVIDE (etext = .);
  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) } >FLASH AT>FLASH :FLASH
  .rodata1        : { *(.rodata1) } >FLASH AT>FLASH :FLASH
  .eh_frame_hdr : { *(.eh_frame_hdr) } >FLASH AT>FLASH :FLASH
  .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) } >FLASH AT>FLASH :FLASH
  .gcc_except_table   : ONLY_IF_RO { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) } >FLASH AT>FLASH :FLASH
  .lalign : { . = ALIGN(8); PROVIDE(_data_lma = .); } >FLASH AT>FLASH :FLASH
  . = ORIGIN(INTRAM);
  .dalign : { . = ALIGN(8); PROVIDE(_data = .); } >INTRAM AT>INTRAM :INTRAM_ALIGN
  /* Exception handling  */
  .eh_frame       : ONLY_IF_RW { KEEP (*(.eh_frame)) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .gcc_except_table   : ONLY_IF_RW { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  /* Thread Local Storage sections  */
  .tdata   : { *(.tdata .tdata.* .gnu.linkonce.td.*) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .tbss   : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  /* Ensure the __preinit_array_start label is properly aligned.  We
     could instead move the label definition inside the section, but
     the linker would then create the section even if it turns out to
     be empty, which isn't pretty.  */
  PROVIDE (__preinit_array_start = ALIGN(32 / 8));
  .preinit_array     : { KEEP (*(.preinit_array)) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  PROVIDE (__preinit_array_end = .);
  PROVIDE (__init_array_start = .);
  .init_array     : { KEEP (*(.init_array)) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  PROVIDE (__init_array_end = .);
  PROVIDE (__fini_array_start = .);
  .fini_array     : { KEEP (*(.fini_array)) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  PROVIDE (__fini_array_end = .);
  .ctors          :
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin*.o(.ctors))
    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .dtors          :
  {
    KEEP (*crtbegin*.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .jcr            : { KEEP (*(.jcr)) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .data.rel.ro : { *(.data.rel.ro.local) *(.data.rel.ro*) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .dynamic        : { *(.dynamic) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .got            : { *(.got.plt) *(.got) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .ramtext        : { *(.ramtext .ramtext.*) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .ddalign : { . = ALIGN(8); } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .data           :
  {
    *(.data .data.* .gnu.linkonce.d.*)
    KEEP (*(.gnu.linkonce.d.*personality*))
    SORT(CONSTRUCTORS)
  } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .data1          : { *(.data1) } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  .balign : { . = ALIGN(8); PROVIDE(_edata = .); } >INTRAM AT>FLASH :INTRAM_AT_FLASH
  PROVIDE (edata = .);
  __bss_start = .;
  .bss            :
  {
    *(.dynbss)
    *(.bss .bss.* .gnu.linkonce.b.*)
    *(COMMON)
    /* Align here to ensure that the .bss section occupies space up to
       _end.  Align after .bss to ensure correct alignment even if the
       .bss section disappears because there are no input sections.  */
    . = ALIGN(8);
  } >INTRAM AT>INTRAM :INTRAM
  . = ALIGN(8);
  _end = .;
  PROVIDE (end = .);
  __heap_start__ = ALIGN(8);
  .heap           :
  {
    *(.heap)
    . = (__heap_size__ == __max_heap_size__) ?
        ORIGIN(INTRAM) + LENGTH(INTRAM) - __stack_size__ - ABSOLUTE(.) :
        __heap_size__;
  } >INTRAM AT>INTRAM :INTRAM
  __heap_end__ = .;
  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  .stack         ORIGIN(INTRAM) + LENGTH(INTRAM) - __stack_size__ :
  {
    _stack = .;
    *(.stack)
    . = __stack_size__;
    _estack = .;
  } >INTRAM AT>INTRAM :INTRAM
  .flash_nvram   ORIGIN(FLASH) + LENGTH(FLASH) - __flash_nvram_size__ (NOLOAD):
  {
    *(.flash_nvram)
  } >FLASH AT>FLASH :FLASH_NVRAM
  .userpage       : { *(.userpage .userpage.*) } >USERPAGE AT>USERPAGE :USERPAGE
  /DISCARD/ : { *(.note.GNU-stack) }
}
Title: Re: Bootloader----S-REC format file
Post by: brintrup on December 28, 2009, 10:35:05 PM
and this is my C linker options

avr32-gcc

-nostartfiles -L../src/SOFTWARE_FRAMEWORK/UTILS/LIBS/NEWLIB_ADDONS -march=ucr1 -Wl,--gc-sections -Wl,-e,_trampoline -Xlinker -T../src/link_uc3b0256.lds -mpart=uc3b0256 -Wl,--gc-sections --rodata-writable -Wl,--direct-data

Regards.
Title: Re: Bootloader----S-REC format file
Post by: mark on December 28, 2009, 11:14:25 PM
Hi

I wonder whether the _trampoline gives some clues?
The reason for this option is discussed here: http://support.atmel.no/bin/customer?=&action=viewKbEntry&id=309 and in more detail in the UC3 USB Bootloader data sheet. It may be that the application is now starting at 0x80002800 but is missing its Sp and PC initialisation (?)

If you debug the code, the serial boot loader should read the value of the stack pointer from 0x80002800 (which should contain the address of the top of RAM) and then loads the PC with the value at 0x80002804, which then causes the application to begin execution from this loaded address. This is in fact exactly the way that a normal HW reset operates, apart from the fact that the SP and PC are at 0x80000000 / 0x80000004 respectively. If you can remove the trampoline stuff (which is not needed together with the uTasker serial loader) it may help. Just read the binary (or SREC) that you generate and verify that the first two long words make sense (that is first the address of the end of RAM, followed by the address of the first instruction of your application code).

Regards

Mark
Title: Re: Bootloader----S-REC format file
Post by: brintrup on December 29, 2009, 11:57:53 PM
Hi mark

I made several changes in my configuration.
In my my linker script (on my own application) I put this:

MEMORY
{
  FLASH (rxai!w) : ORIGIN = 0x80002800, LENGTH = 0x00040000
  INTRAM (wxa!ri) : ORIGIN = 0x00000104, LENGTH = 0x00008000 - 0x104
  USERPAGE : ORIGIN = 0x80800000, LENGTH = 0x00000200
}

and in my GNU linker options are:

avr32-gcc
-nostartfiles -L../src/SOFTWARE_FRAMEWORK/UTILS/LIBS/NEWLIB_ADDONS -march=ucr1 -Wl,--gc-sections -Wl -Xlinker -T../src/link_uc3b0256.lds -mpart=uc3b0256 -Wl,--gc-sections --rodata-writable -Wl,--direct-data

but the application seems not launch.

Thanks in advanced.
Title: Re: Bootloader----S-REC format file
Post by: mark on December 30, 2009, 12:20:51 AM
Hi

Since I now also have an EVK1101 it may be an idea when I load the same file to my board with the loader installed.
If you could send me the SREC plus a map file I may be able to debug it and see why it doesn't start.

Regards

Mark

Title: Re: Bootloader----S-REC format file
Post by: mark on December 30, 2009, 05:51:23 PM
Hi

I received the SREC and successfully loaded it to my EVK1101 using the UC3B serial loader (I set it to accept 140k code since your code is about 120k in size).

1) I have to correct my statement from the previous posts since the AVr32 start-up is not with SP + PC but instead the first instruction generally sets the SP. This means that the boot loader simple jumps to the address 0x080002800. Your code is OK since it then loads the PC with the address 0x8000bc3c and jumps to there, where the stack pointer is also correctly configured to 0x00008000.

2) Your code runs to the call 0x80012660 but never returns from it. Therefore the code does start and runs though about 20 calls or so before getting stick here.

3) I notice that at the start of the code the instruction MTSR EVBA, 0x8001b00 is executed. This is setting the exception vector base address to this area - where the exception vectors should reside (I think that they must be within a 16k block when this method is used).

Therefore I don't actually see a problem with the code not starting. I suggest that you try debugging the routine at 0x80012660 to see why it never returns from there. I saw that it stuck in a loop but I didn't see what it was waiting for.
Also note that the serial boot loader activates the watchdog; if your loop is intentional, it will cause the watchdog to fire after a short time and so result in a reset and a continuous repetition of this process. By holding the PB1 button at reset the watchdog is not started and so your code will stay in this loop without the watchdog firing - does this give any ideas?

Regards

Mark

Title: Re: Bootloader----S-REC format file
Post by: mark on January 15, 2010, 08:15:52 PM
Hi All

For anyone monitoring this thread, the solution was found as follows:

1) The application that was being loaded was not triggering the watchdog so the watchdog needed to be disabled in the boot loader so that it didn't fire once the application was started.

2) The boot loader (as all uTasker projects) disables the peripheral clocks by default in order to save power consumption - the application then needs to enable each required peripheral clock before use. Alternatively the peripheral clocks are left enabled in the boot loader and then the application doesn't need to be concerned with enabling them (although unused peripherals may be consuming unnecessary power).

Regards

Mark