SparkFun Forums 

Where electronics enthusiasts find answers.

Open source ARM Debugger
By Gorlash
#49784
I'm using OpenOCD (r657) to download code to a Hitex comStick.
I have code mapped to flash at address 0. Here's what I see when I download my file:

> reset halt
JTAG device found: 0x04570041 (Manufacturer: 0x020, Part: 0x4570, Version: 0x0)
JTAG device found: 0x25966041 (Manufacturer: 0x020, Part: 0x5966, Version: 0x2)
JTAG device found: 0x2457f041 (Manufacturer: 0x020, Part: 0x457f, Version: 0x2)
target state: halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
> flash write_image erase c:\download\odu\odu\odu.elf 0 elf
auto erase enabled
No flash at address 0x04000000

wrote 183064 byte from file c:\download\odu\odu\odu.elf in 14.910795s (11.989531 kb/s)
> reset run
JTAG device found: 0x04570041 (Manufacturer: 0x020, Part: 0x4570, Version: 0x0)
JTAG device found: 0x25966041 (Manufacturer: 0x020, Part: 0x5966, Version: 0x2)
JTAG device found: 0x2457f041 (Manufacturer: 0x020, Part: 0x457f, Version: 0x2)
>
//*********************************************
the header from my .elf file:
> readelf -S odu.elf
There are 18 section headers, starting at offset 0x67a20:

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 02cb18 00 AX 0 0 4
[ 2] .data PROGBITS 04000000 038000 000b10 00 WA 0 0 4
[ 3] .bss NOBITS 04000b10 038b10 00aa50 00 WA 0 0 4
[ 4] .comment PROGBITS 00000000 038b10 000132 00 0 0 1

//*********************************************

So everything *looks* like it's correct, but what does that "no flash at address 0x04000000" mean?? Of *course* there's no flash at 0x4000000, that's RAM there, I never told it to put anything there (that I know of) ... ???

My str912.cfg:
#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "STR9-comStick A"
ft2232_layout comstick
jtag_speed 1

#delays on reset lines
jtag_nsrst_delay 100
jtag_ntrst_delay 100

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 8 0x1 0x1 0xfe
jtag_device 4 0x1 0xf 0xe
jtag_device 5 0x1 0x1 0x1e

#target configuration
daemon_startup reset

#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm966e little reset_halt 1 arm966e
run_and_halt_time 0 30

target_script 0 reset event/str912_reset.script

target_script 0 gdb_program_config event/str912_program.script

working_area 0 0x50000000 16384 nobackup

#flash bank str9x <base> <size> 0 0 <target#> <variant>
flash bank str9x 0x00000000 0x00080000 0 0 0
#flash bank str9x 0x00080000 0x00008000 0 0 0

//************************************************
Any ideas as to why this message is occurring?? Do I care??
User avatar
By ntfreak
#49906
What happens if you try a hex or s19 file?
Just done a quick test and it is working ok here.

Have you configured the flash controller and removed the protection, eg.
str9x flash_config 0 4 2 0 0x80000
flash protect 0 0 7 off
flash write_image erase comstick.elf

then to verify
verify_image comstick.elf

Cheers
Spen
By Gorlash
#49915
Okay, that's interesting...
I tried all your other suggestions, with no effect.
Downloading a hex file had the same effect as downloading elf.

So, I downloaded the elf file again, then tried verify_image...
and it says:
> verify_image c:\download\odu\odu\odu.elf
checksum mismatch - attempting binary compare
Verify operation failed address 0x04000000. Was 0x03 instead of 0x36

So it really *does* think I want my code located at the RAM address... why does it think that?? My str912.cfg says
flash bank str9x 0x00000000 0x00080000 0 0 0
whereas it doesn't say *anything* about 0x4000000
Where is that address actually set??
User avatar
By ntfreak
#49916
the only thing i can suggest is to double check your linker script.
could you provide a link to the source?

Cheers
Spen
By Gorlash
#49927
Okay, I put together a package with the makefile, .ld file, startup source, and my OpenOCD config file. I presume the decision-making data is somewhere in one of those files?? Though, nowhere do I tell it to do anything with 0x4000000

http://home.comcast.net/~derelict/files/str9.files.zip
User avatar
By ntfreak
#49933
The problem is caused because you are telling the data section to be loaded in RAM - at adr 0x4000000

you commented out the .data : AT (_sidata) line which is very important.

here is one of my linker scripts for the str9
Code: Select all
/***********************************************************************************
*	Copyright 2005 Anglia Design
*	This demo code and associated components are provided as is and has no warranty,
*	implied or otherwise.  You are free to use/modify any of the provided
*	code at your own risk in your applications with the expressed limitation
*	of liability (see below)
* 
*	LIMITATION OF LIABILITY:   ANGLIA OR ANGLIA DESIGNS SHALL NOT BE LIABLE FOR ANY
*	LOSS OF PROFITS, LOSS OF USE, LOSS OF DATA, INTERRUPTION OF BUSINESS, NOR FOR
*	INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND WHETHER UNDER
*	THIS AGREEMENT OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
*
*	Author			: Spencer Oliver
*	Web     		: www.anglia-designs.com
*
***********************************************************************************/

ENTRY(Reset_Vec)

/* Stack Sizes */

	_STACKSIZE = 1024;
	_STACKSIZE_IRQ = 256;
	_STACKSIZE_FIQ = 256;
	_STACKSIZE_SVC = 0;
	_STACKSIZE_ABT = 0;
	_STACKSIZE_UND = 0;
	_HEAPSIZE = 1024;

/* Memory Definitions */

MEMORY
{
	CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x00080000
	DATA (rw) : ORIGIN = 0x04000000, LENGTH = 0x00018000
}

/* Section Definitions */

SECTIONS
{
	/* first section is .text which is used for code */

	.text :
	{
		CREATE_OBJECT_SYMBOLS
		KEEP(*(.vectors))
		KEEP(*(.init))
		*(.text .text.*)
		*(.gnu.linkonce.t.*)
		*(.glue_7t) *(.glue_7) *(.vfp11_veneer)
		KEEP(*(.fini))
		*(.gcc_except_table)
	} >CODE =0
	. = ALIGN(4);

	/* .ctors .dtors are used for c++ constructors/destructors */
	
	.ctors :
	{
		PROVIDE(__ctors_start__ = .);
		KEEP(*(SORT(.ctors.*)))
		KEEP(*(.ctors))
		PROVIDE(__ctors_end__ = .);
	} >CODE

	.dtors :
	{
		PROVIDE(__dtors_start__ = .); 
		KEEP(*(SORT(.dtors.*)))
		KEEP(*(.dtors))
		PROVIDE(__dtors_end__ = .);
	} >CODE
	
	/* .rodata section which is used for read-only data (constants) */

	.rodata :
	{
		*(.rodata .rodata.*)
		*(.gnu.linkonce.r.*)
	} >CODE
	. = ALIGN(4);

	.init_array :
	{
		*(.init)
        *(.fini)
		PROVIDE_HIDDEN (__preinit_array_start = .);
		KEEP (*(.preinit_array))
		PROVIDE_HIDDEN (__preinit_array_end = .);
		PROVIDE_HIDDEN (__init_array_start = .);
		KEEP (*(SORT(.init_array.*)))
		KEEP (*(.init_array))
		PROVIDE_HIDDEN (__init_array_end = .);
		PROVIDE_HIDDEN (__fini_array_start = .);
		KEEP (*(.fini_array))
		KEEP (*(SORT(.fini_array.*)))
		PROVIDE_HIDDEN (__fini_array_end = .);
	} >CODE

	. = ALIGN(4);

	/* .ARM.exidx is sorted, so has to go in its own output section.  */
	__exidx_start = .;
	.ARM.exidx :
	{
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
	} >CODE
	__exidx_end = .;

	_etext = .;
	PROVIDE (etext = .);

	/* .data section which is used for initialized data */

	.data : AT (_etext)
	{
		__data_start = .;
		*(.data .data.*)
		*(.gnu.linkonce.d.*)
		SORT(CONSTRUCTORS)
		. = ALIGN(4);
		*(.fastrun .fastrun.*)
	} >DATA
	. = ALIGN(4);
	
	_edata = .;
	PROVIDE (edata = .);

	/* .bss section which is used for uninitialized data */

	.bss :
	{
		__bss_start = .;
		__bss_start__ = .;
		*(.bss .bss.*)
		*(.gnu.linkonce.b.*)
		*(COMMON)
		. = ALIGN(4);
	} >DATA
	. = ALIGN(4);
	__bss_end__ = .;
	
	_end = .;
	PROVIDE(end = .);

	/* .heap section which is used for memory allocation */
	
	.heap (NOLOAD) :
	{
		__heap_start__ = .;
		*(.heap)
		. = MAX(__heap_start__ + _HEAPSIZE , .);
	} >DATA
	__heap_end__ = __heap_start__ + SIZEOF(.heap);
	
	/* .stack section - user mode stack */
	
	.stack (__heap_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		__stack_start__ = .;
		*(.stack)
		. = MAX(__stack_start__ + _STACKSIZE , .);
	} >DATA
	__stack_end__ = __stack_start__ + SIZEOF(.stack);

	/* .stack_irq section */
	
	.stack_irq (__stack_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		__stack_irq_start__ = .;
		*(.stack_irq)
		. = MAX(__stack_irq_start__ + _STACKSIZE_IRQ , .);
	} >DATA
	__stack_irq_end__ = __stack_irq_start__ + SIZEOF(.stack_irq);

	/* .stack_fiq section */
	
	.stack_fiq (__stack_irq_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		__stack_fiq_start__ = .;
		*(.stack_fiq)
	    . = MAX(__stack_fiq_start__ + _STACKSIZE_FIQ , .);
	} >DATA
	__stack_fiq_end__ = __stack_fiq_start__ + SIZEOF(.stack_fiq);

	/* .stack_svc section */
	
	.stack_svc (__stack_fiq_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		__stack_svc_start__ = .;
		*(.stack_svc)
		. = MAX(__stack_svc_start__ + _STACKSIZE_SVC , .);
	} >DATA
	__stack_svc_end__ = __stack_svc_start__ + SIZEOF(.stack_svc);

	/* .stack_abt section */
	
	.stack_abt (__stack_svc_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		__stack_abt_start__ = .;
		*(.stack_abt)
		. = MAX(__stack_abt_start__ + _STACKSIZE_ABT , .);
	} >DATA
	__stack_abt_end__ = __stack_abt_start__ + SIZEOF(.stack_abt);

	/* .stack_und section */
	
	.stack_und (__stack_abt_end__ + 3) / 4 * 4 (NOLOAD) :
	{
		__stack_und_start__ = .;
		*(.stack_und)
    	. = MAX(__stack_und_start__ + _STACKSIZE_UND , .);
	} >DATA
	__stack_und_end__ = __stack_und_start__ + SIZEOF(.stack_und);
  
	/* 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) }	
}
Cheers
Spen
By Gorlash
#49934
Amazing!!! I actually took that out (the .data statement with AT ()) because in some earlier attempt at figuring out the ld script, that form was giving an error!! Now, of course, it compiles fine, and indeed, the 0x4000000 error in OpenOCD is no longer occurring!!

Thank you very much!!! Now I'll go back and re-read the section on scripts in the ld manual.