str9x_write(): flash writing failed

danglin · October 2, 2007, 9:01pm

I currently using a str9-comstick with openocd and developing

the basic setup for a new project. I have the ST Micro firmware

building within eclipse. The project’s flash image and elf file

successfully load the first time I start openocd and gdb. However,

if I quit gdb and restart it (either within eclipse or by manually

running arm-elf-gdb), the flash load fails. I see this in the openocd

log when I turnon debug output:

…

armv4_5.c:647 armv4_5_run_algorithm(): restoring register pc with value 0x00000000

Debug: armv4_5.c:647 armv4_5_run_algorithm(): restoring register spsr_svc with value 0x00000010

Error: str9x.c:409 str9x_write_block(): error executing str9x flash write algorithm

Error: str9x.c:488 str9x_write(): flash writing failed with error code: 0xfffffc7a

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$O6661696c65642077726974696e672066696c65206d61696e2e62696e20746f20666c6173682062616e6b2030206174206f666673657420307830303030303030300a#9f’

Debug: gdb_server.c:126 gdb_get_char(): received ‘—+$k#6b$k#6b+’

Warning: gdb_server.c:197 gdb_put_packet(): negative reply, retrying

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$O6661696c65642077726974696e672066696c65206d61696e2e62696e20746f20666c6173682062616e6b2030206174206f666673657420307830303030303030300a#9f’

Warning: gdb_server.c:197 gdb_put_packet(): negative reply, retrying

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$O6661696c65642077726974696e672066696c65206d61696e2e62696e20746f20666c6173682062616e6b2030206174206f666673657420307830303030303030300a#9f’

Warning: gdb_server.c:197 gdb_put_packet(): negative reply, retrying

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$O6661696c65642077726974696e672066696c65206d61696e2e62696e20746f20666c6173682062616e6b2030206174206f666673657420307830303030303030300a#9f’

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$O666c6173682070726f6772616d206572726f720a#6d’

Error: gdb_server.c:215 gdb_put_packet(): unknown character 0x24 in reply, dropping connection

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$O77726f7465202038393220627974652066726f6d2066696c65206d61696e2e62696e20746f20666c6173682062616e6b2030206174206f6666736574203078303030303030303020696e203135732037303330303075732028302e303535343733206b622f73290a#c2’

Error: gdb_server.c:215 gdb_put_packet(): unknown character 0x6b in reply, dropping connection

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$OK#9a’

Error: gdb_server.c:215 gdb_put_packet(): unknown character 0x23 in reply, dropping connection

Debug: gdb_server.c:239 gdb_get_packet(): character: ‘6’

Warning: gdb_server.c:256 gdb_get_packet(): ignoring character 0x36

Debug: gdb_server.c:239 gdb_get_packet(): character: ‘b’

Warning: gdb_server.c:256 gdb_get_packet(): ignoring character 0x62

Debug: gdb_server.c:239 gdb_get_packet(): character: ‘$’

Debug: gdb_server.c:1338 gdb_input(): received packet: ‘k’

Debug: gdb_server.c:179 gdb_put_packet(): sending packet ‘$OK#9a’

Info: server.c:360 server_loop(): dropped ‘gdb’ connection

At this point, I’m not sure why flash writing fails when gdb is restarted.

It doesn’t fail if I repeat the flash write within a gdb session. It would

seem something isn’t being reset/initialized the gdb connection is

dropped/connected. Eclipse isn’t too happy about the gdb server

dropping connections.

I’ve noticed that there is a problem with working areas target_free_working_area() doesn’t seem to ever get called. So,

we never free and reuse working areas. So, each time I restart gdb,

the working areas get smaller and smaller. Ultimately, this would

cause flash writes to fail, but it doesn’t seem to be the problem the

second time around.

Finally, svn seems broken at the moment. svn can’t seem to

connect to host svn.berlios.de at the moment.

ntfreak · October 3, 2007, 2:47pm

you are quite correct, just checked the str9 code and it does not free the working area - i will commit changes to svn.

Regarding your other problem, can you give all your scripts etc.

Regards

Spen

danglin · October 4, 2007, 8:22pm

My previous attempts at replying seem to be held. The following

patch resolves the working area problem.

Index: src/server/gdb_server.c

===================================================================

— src/server/gdb_server.c (revision 208)

+++ src/server/gdb_server.c (working copy)

@@ -1335,7 +1335,7 @@

/* terminate with zero */

packet[packet_size] = 0;

DEBUG(“recevied packet: ‘%s’”, packet);

DEBUG(“received packet: ‘%s’”, packet);

if (packet_size > 0)

{

Index: src/target/arm7_9_common.c

===================================================================

— src/target/arm7_9_common.c (revision 208)

+++ src/target/arm7_9_common.c (working copy)

@@ -704,12 +704,12 @@

{

int retval;

/* There might be working areas allocated */
target_free_all_working_areas(target);

DEBUG(“target->state: %s”, target_state_strings[target->state]);

if (target->state == TARGET_HALTED || target->state == TARGET_UNKNOWN)

{

/* if the target wasn’t running, there might be working areas allocated */
target_free_all_working_areas(target);

/* assert SRST and TRST */

/* system would get ouf sync if we didn’t reset test-logic, too */

@@ -830,6 +830,9 @@

reg_t *dbg_ctrl = &arm7_9->eice_cache->reg_list[EICE_DBG_CTRL];

int i;

/* There might be working areas allocated */
target_free_all_working_areas(target);

if (target->state == TARGET_RUNNING)

{

target->type->halt(target);

There’s still a problem when no working area is specified. More

details are in my previous posts. The simplest way to see this is

to do a flash write without a working area.

ntfreak · October 4, 2007, 9:04pm

thanks for the patch, i will look into it.

This is the current fix for the str9 problem of not freeing memory.

Index: str9x.c
===================================================================
--- str9x.c	(revision 208)
+++ str9x.c	(working copy)
@@ -28,6 +28,7 @@
 #include "target.h"
 #include "log.h"
 #include "armv4_5.h"
+#include "arm966e.h"
 #include "algorithm.h"
 #include "binarybuffer.h"
 
@@ -355,20 +356,17 @@
 	int i;
 	
 	/* flash write code */
-	if (!str9x_info->write_algorithm)
+	if (target_alloc_working_area(target, 4 * 19, &str9x_info->write_algorithm) != ERROR_OK)
 	{
-		if (target_alloc_working_area(target, 4 * 19, &str9x_info->write_algorithm) != ERROR_OK)
-		{
-			WARNING("no working area available, can't do block memory writes");
-			return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
-		};
+		WARNING("no working area available, can't do block memory writes");
+		return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+	};
 
-		/* convert flash writing code into a buffer in target endianness */
-		for (i = 0; i < 19; i++)
-			target_buffer_set_u32(target, str9x_flash_write_code_buf + i*4, str9x_flash_write_code[i]);
-			
-		target_write_buffer(target, str9x_info->write_algorithm->address, 19 * 4, str9x_flash_write_code_buf);
-	}
+	/* convert flash writing code into a buffer in target endianness */
+	for (i = 0; i < 19; i++)
+		target_buffer_set_u32(target, str9x_flash_write_code_buf + i*4, str9x_flash_write_code[i]);
+		
+	target_write_buffer(target, str9x_info->write_algorithm->address, 19 * 4, str9x_flash_write_code_buf);
 
 	/* memory buffer */
 	while (target_alloc_working_area(target, buffer_size, &source) != ERROR_OK)
@@ -383,7 +381,7 @@
 			WARNING("no large enough working area available, can't do block memory writes");
 			return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
 		}
-	};
+	}
 	
 	armv4_5_info.common_magic = ARMV4_5_COMMON_MAGIC;
 	armv4_5_info.core_mode = ARMV4_5_MODE_SVC;
@@ -406,6 +404,8 @@
 
 		if ((retval = target->type->run_algorithm(target, 0, NULL, 4, reg_params, str9x_info->write_algorithm->address, str9x_info->write_algorithm->address + (18 * 4), 10000, &armv4_5_info)) != ERROR_OK)
 		{
+			target_free_working_area(target, source);
+			target_free_working_area(target, str9x_info->write_algorithm);
 			ERROR("error executing str9x flash write algorithm");
 			return ERROR_FLASH_OPERATION_FAILED;
 		}
@@ -420,6 +420,9 @@
 		count -= thisrun_count;
 	}
 	
+	target_free_working_area(target, source);
+	target_free_working_area(target, str9x_info->write_algorithm);
+	
 	destroy_reg_param(&reg_params[0]);
 	destroy_reg_param(&reg_params[1]);
 	destroy_reg_param(&reg_params[2]);
@@ -618,6 +621,9 @@
     target_write_u32(target, FLASH_BBADR, (strtoul(args[2], NULL, 0) >> 2));
     target_write_u32(target, FLASH_NBBADR, (strtoul(args[3], NULL, 0) >> 2));
 
+	/* set b18 instruction TCM order as per flash programming manual */
+	arm966e_write_cp15(target, 62, 0x40000);
+	
 	/* enable flash bank 1 */
     target_write_u32(target, FLASH_CR, 0x18);
 	return ERROR_OK;

I have not committed to svn yet as i am working on a few other changes.

Cheers

Spen

danglin · October 10, 2007, 2:47pm

Thanks, your patch and updating to revision 209 fix the working area problem. However, there is still a problem with flash loads when a working area is not specified. The following command fails with a packet error:

#Load flash
monitor flash write 0 main.bin 0

This is what gdb outputs:

...
Ignoring packet error, continuing...
/cygdrive/c/Documents and Settings/dave_e/My Documents/ECLIPSE/worspace/OM200 OCB/gdbinit:85: Error in sourced command file:
Reply contains invalid hex digit 115

It appears from the openocd log that the error occurs after it has completed writing to flash the main.bin image. Here is the log:

Debug: arm966e.c:139 arm966e_target_command(): chain_pos: 1, variant: arm966e

Debug: jtag.c:1407 jtag_init(): -

Debug: ft2232.c:1300 ft2232_init_ftd2xx(): ‘ft2232’ interface using FTD2XX with ‘comstick’ layout (0640:002c)

Debug: ft2232.c:1389 ft2232_init_ftd2xx(): current latency timer: 2

Debug: ft2232.c:1888 comstick_init(): 80 08 0b

Debug: ft2232.c:1908 comstick_init(): 82 03 03

Debug: ft2232.c:255 ft2232_speed(): 86 01 00

Debug: jtag.c:295 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1197 jtag_reset_callback(): -

Debug: jtag.c:295 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1197 jtag_reset_callback(): -

Debug: jtag.c:1291 jtag_examine_chain(): JTAG device found: 0x04570041 (Manufacturer: 0x020, Part: 0x4570, Version: 0x0

Debug: jtag.c:1291 jtag_examine_chain(): JTAG device found: 0x25966041 (Manufacturer: 0x020, Part: 0x5966, Version: 0x2

Debug: jtag.c:1291 jtag_examine_chain(): JTAG device found: 0x2457f041 (Manufacturer: 0x020, Part: 0x457f, Version: 0x2

Debug: jtag.c:295 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1197 jtag_reset_callback(): -

Debug: openocd.c:113 main(): jtag init complete

Debug: embeddedice.c:220 embeddedice_read_reg_w_check(): 4

Debug: jtag.c:295 jtag_call_event_callbacks(): jtag event: TRST released

Debug: jtag.c:1197 jtag_reset_callback(): -

Debug: embeddedice.c:220 embeddedice_read_reg_w_check(): 0

Debug: embeddedice.c:384 embeddedice_write_reg(): 0: 0x00000000

Debug: embeddedice.c:220 embeddedice_read_reg_w_check(): 1

Debug: arm7_9_common.c:671 arm7_9_poll(): DBGACK set, dbg_state->value: 0x2cd

Warning: arm7_9_common.c:674 arm7_9_poll(): DBGACK set while target was in unknown state. Reset or initialize target before resuming

Debug: embeddedice.c:384 embeddedice_write_reg(): 0: 0x00000005

Debug: arm7_9_common.c:1047 arm7_9_debug_entry(): target entered debug from ARM state

Debug: arm7_9_common.c:1079 arm7_9_debug_entry(): target entered debug state in Supervisor mode

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r0: 0x600000d3

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r1: 0xe14f1000

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r2: 0xe1500001

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r3: 0x20400001

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r4: 0xe12fff1e

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r5: 0xe52de008

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r6: 0xebfffc24

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r7: 0xe3a00000

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r8: 0xe49de008

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r9: 0xe12fff1e

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r10: 0xe1500001

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r11: 0x20400001

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r12: 0xe1a010a1

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r13: 0xe1500001

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r14: 0x20400001

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r15: 0x5001d11c

Debug: arm7_9_common.c:1114 arm7_9_debug_entry(): entered debug state at PC 0x5001d11c

Debug: target.c:469 target_call_event_callbacks(): target event 0

Debug: arm7_9_common.c:1431 arm7_9_resume(): -

Debug: arm7_9_common.c:1230 arm7_9_restore_context(): -

Debug: arm7_9_common.c:1246 arm7_9_restore_context(): examining User mode

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: r0

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1309 arm7_9_restore_context(): writing register 0 of mode User with value 0x600000d3

Debug: arm7_9_common.c:1246 arm7_9_restore_context(): examining FIQ mode

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1246 arm7_9_restore_context(): examining IRQ mode

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1246 arm7_9_restore_context(): examining Supervisor mode

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1246 arm7_9_restore_context(): examining Abort mode

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1246 arm7_9_restore_context(): examining Undefined mode

Debug: arm7_9_common.c:1260 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1349 arm7_9_restore_context(): writing PC with value 0x5001d11c

Debug: embeddedice.c:384 embeddedice_write_reg(): 0: 0x00000004

Debug: target.c:469 target_call_event_callbacks(): target event 4

Debug: arm7_9_common.c:1534 arm7_9_resume(): target resumed

Debug: embeddedice.c:384 embeddedice_write_reg(): 2: 0x00000001

Debug: arm7_9_common.c:707 arm7_9_assert_reset(): target->state: debug_running

Debug: jtag.c:295 jtag_call_event_callbacks(): jtag event: SRST asserted

Debug: jtag.c:1197 jtag_reset_callback(): -

Debug: ft2232.c:1073 comstick_reset(): trst: 0, srst: 1, high_output: 0x01, high_direction: 0x03

Debug: arm7_9_common.c:929 arm7_9_halt(): target->state: reset

Debug: arm7_9_common.c:773 arm7_9_deassert_reset(): target->state: reset

Debug: jtag.c:295 jtag_call_event_callbacks(): jtag event: SRST released

Debug: jtag.c:1197 jtag_reset_callback(): -

Debug: ft2232.c:1073 comstick_reset(): trst: 0, srst: 0, high_output: 0x03, high_direction: 0x03

Debug: openocd.c:117 main(): target init complete

Debug: openocd.c:121 main(): flash init complete

Debug: openocd.c:125 main(): NAND init complete

Debug: openocd.c:129 main(): pld init complete

Debug: gdb_server.c:1484 gdb_init(): gdb service for target arm966e at port 3333

Debug: embeddedice.c:220 embeddedice_read_reg_w_check(): 1

Debug: arm7_9_common.c:671 arm7_9_poll(): DBGACK set, dbg_state->value: 0x10d

Debug: embeddedice.c:384 embeddedice_write_reg(): 0: 0x00000005

Debug: arm7_9_common.c:1047 arm7_9_debug_entry(): target entered debug from ARM state

Debug: arm7_9_common.c:1079 arm7_9_debug_entry(): target entered debug state in Supervisor mode

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r0: 0x600000d3

Debug: arm7_9_common.c:1108 arm7_9_debug_entry(): r1: 0x600000d7