Open OCD, STR912, flash-programming quirk

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

#target arm7tdmi

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 0 0 <target#>

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??

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

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??

the only thing i can suggest is to double check your linker script.

could you provide a link to the source?

Cheers

Spen

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

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

/***********************************************************************************
*	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

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.