Author Topic: Bootloader----S-REC format file  (Read 51890 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #15 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



Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #16 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

Offline FAQ

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: Bootloader----S-REC format file
« Reply #17 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?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #18 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

Offline brintrup

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bootloader----S-REC format file
« Reply #19 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.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #20 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

Offline brintrup

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bootloader----S-REC format file
« Reply #21 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) }
}

Offline brintrup

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bootloader----S-REC format file
« Reply #22 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.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #23 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

Offline brintrup

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bootloader----S-REC format file
« Reply #24 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.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #25 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


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #26 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


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3240
    • View Profile
    • uTasker
Re: Bootloader----S-REC format file
« Reply #27 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