STM32 write flash error

My OpenOCD is SVN 695

My log file:

Debug: 1137 18895 command.c:430 command_run_line(): sleep 10

Debug: 1138 18906 command.c:430 command_run_line(): mdw 0x40010C00 7

Debug: 1139 18906 cortex_swjdp.c:671 ahbap_read_buf_u32(): Looooooooook

Debug: 1140 18906 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xA2000012 to 0x00000000

Debug: 1141 18906 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0x40010C00 to 0x00000004

Info: 1142 19008 options.c:50 configuration_output_handler(): 0x40010c00: 44484444 44444441 0000fe13 00000010 00000000 00000000 00000000

Debug: 1143 19008 command.c:430 command_run_line(): sleep 10

Debug: 1144 19019 command.c:430 command_run_line(): mww 0x40010C0C 0x00000000

Debug: 1145 19019 cortex_swjdp.c:408 ahbap_write_buf_u32(): Looooooooook, count = 4, address = 0x40010C0C

Debug: 1146 19019 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0x40010C0C to 0x00000004

Debug: 1147 19063 command.c:430 command_run_line(): sleep 10

Debug: 1148 19074 command.c:430 command_run_line(): mdw 0x08000000 1

Debug: 1149 19074 cortex_swjdp.c:671 ahbap_read_buf_u32(): Looooooooook

Debug: 1150 19074 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0x08000000 to 0x00000004

Info: 1151 19126 options.c:50 configuration_output_handler(): 0x08000000: 20002000

Debug: 1152 19126 command.c:430 command_run_line(): sleep 10

Debug: 1153 19137 command.c:430 command_run_line(): mww 0x08000000 0x00000000

Debug: 1154 19137 cortex_swjdp.c:408 ahbap_write_buf_u32(): Looooooooook, count = 4, address = 0x08000000

Debug: 1155 19137 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0x08000000 to 0x00000004

Debug: 1156 19180 cortex_swjdp.c:208 swjdp_transaction_endcheck(): swjdp: CTRL/STAT error 0xf0000021

Error: 1157 19180 cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR

Debug: 1158 19195 cortex_swjdp.c:229 swjdp_transaction_endcheck(): swjdp: status 0xf0000001

Debug: 1159 19195 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000EDF0

Debug: 1160 19195 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xA2000002 to 0x00000000

Debug: 1161 19195 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xE000EDF0 to 0x00000004

Debug: 1162 19196 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000010

Debug: 1163 19268 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000ED24

Debug: 1164 19268 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xE000ED20 to 0x00000004

Debug: 1165 19268 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000014

Debug: 1166 19342 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000ED28

Debug: 1167 19342 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000018

Debug: 1168 19389 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000ED38

Debug: 1169 19389 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xE000ED30 to 0x00000004

Debug: 1170 19389 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000018

Error: 1171 19462 cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Debug: 1172 19462 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xA2000012 to 0x00000000

Debug: 1173 19462 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0x08000000 to 0x00000004

Debug: 1174 19514 cortex_swjdp.c:208 swjdp_transaction_endcheck(): swjdp: CTRL/STAT error 0xf0000021

Error: 1175 19514 cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR

Debug: 1176 19529 cortex_swjdp.c:229 swjdp_transaction_endcheck(): swjdp: status 0xf0000001

Debug: 1177 19529 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000EDF0

Debug: 1178 19529 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xA2000002 to 0x00000000

Debug: 1179 19529 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xE000EDF0 to 0x00000004

Debug: 1180 19530 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000010

Debug: 1181 19604 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000ED24

Debug: 1182 19604 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xE000ED20 to 0x00000004

Debug: 1183 19604 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000014

Debug: 1184 19679 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000ED28

Debug: 1185 19679 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000018

Debug: 1186 19726 cortex_swjdp.c:362 ahbap_read_system_atomic_u32(): Looooooooook,read 0xE000ED38

Debug: 1187 19726 cortex_swjdp.c:294 ahbap_write_reg_u32(): Looooooooook,write 0xE000ED30 to 0x00000004

Debug: 1188 19726 cortex_swjdp.c:305 ahbap_read_reg_u32(): Looooooooook,read 0x00000018

Error: 1189 19799 cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Warning: 1190 19799 cortex_swjdp.c:464 ahbap_write_buf_u32(): Block write error address 0x8000000, wcount 0x1

Debug: 1191 19799 command.c:387 find_and_run_command(): Command failed with error code -107

commands:

sleep 10

mdw 0x40010C00 7 // get the right value

sleep 10

mww 0x40010C0C 0x00000000 // OK, LEDs are set off(0x40010C0C is GPIOB_ODR which control the GPIO Output Data)

sleep 10

mdw 0x08000000 1 // read flash 0x08000000, the value read is OK the same as the program

sleep 10

mww 0x08000000 0x00000000 // write 0 to flash address 0x08000000, this fails, why?

Other commands run well, so I think there is no problem with the hardware. But why last write flash command fails?

How should I write flash word?

to write to flash you need to use the flash commands

eg.

flash write_image image.bin

also make sure the stm flash is configured, eg.

working_area 0 0x20000000 16384 nobackup

flash bank stm32x 0 0 0 0 0

Regards

Spen

Yes, I write flash by command: flash write_image demo.bin 0x08000000 bin

I ask this question because I found some problems when working with IAR EWARM Kickstart 5.11B thru DBG Server. IAR 5.11 always fails to write flash, below is the debug log:

Debug: 213 6215 target.c:425 target_process_reset(): Polling target

Info: 214 17098 server.c:78 add_connection(): accepting ‘gdb’ connection from 0

Debug: 215 17098 cortex_m3.c:452 cortex_m3_halt(): target->state: halted

Debug: 216 17098 cortex_m3.c:456 cortex_m3_halt(): target was already halted

Debug: 217 17401 gdb_server.c:1878 gdb_input_inner(): received packet: ‘’

Debug: 218 17402 gdb_server.c:1878 gdb_input_inner(): received packet: ‘?’

Debug: 219 17402 gdb_server.c:1878 gdb_input_inner(): received packet: ‘M8000000,c8:00200020e1060008390500083d05000841050008450500084905000800000000000000000000000000000000510500084d0500080000000055050008590500085d0500086105000865050008690500086d0500087105000875050008790500087d0500088105000885050008890500088d0500089105000895050008990500089d050008a1050008a5050008a9050008ad050008b1050008b5050008b9050008bd050008c1050008c5050008c9050008cd050008d1050008d5050008d9050008dd050008e1050008’

Debug: 220 17402 gdb_server.c:1143 gdb_write_memory_packet(): addr: 0x08000000, len: 0x000000c8

Debug: 221 17402 target.c:979 target_write_buffer(): writing buffer of 200 byte at 0x08000000

Debug: 222 17402 cortex_swjdp.c:408 ahbap_write_buf_u32(): Looooooooook, count = 200, address = 0x08000000

Debug: 223 17652 cortex_swjdp.c:208 swjdp_transaction_endcheck(): swjdp: CTRL/STAT error 0xf0000021

Error: 224 17652 cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR

Debug: 225 17668 cortex_swjdp.c:229 swjdp_transaction_endcheck(): swjdp: status 0xf0000001

Error: 226 17943 cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Debug: 227 18192 cortex_swjdp.c:208 swjdp_transaction_endcheck(): swjdp: CTRL/STAT error 0xf0000021

Error: 228 18192 cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR

Debug: 229 18208 cortex_swjdp.c:229 swjdp_transaction_endcheck(): swjdp: status 0xf0000001

Error: 230 18481 cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Warning: 231 18481 cortex_swjdp.c:464 ahbap_write_buf_u32(): Block write error address 0x8000000, wcount 0x32

Error: 232 18481 gdb_server.c:1024 gdb_error(): unexpected error -107

IAR attemp to write flash in the same way as I mentioned above(thru command ahbap_write_buf_u32), so it fails.

Is it a bug?

And I found some other bugs when using IAR, after this bug is solved(If it is a bug), I’ll make further test.

Best Regards, Simon Qian

Simon ,

Last time i tried IAR worked fine with the gdbsever and openocd.

Have you selected the Flash loader in the download tab?

as iar will write a flash loader to program the flash.

Cheers

Spen

Thank U for your quick reply.

After enable the Flash loader, I got this:

Sat May 31 03:20:06 2008: Logging to file: H:\STM32F103VHB6_RevZ_Demo1\cspycomm.log

Sat May 31 03:20:25 2008: 5780 bytes downloaded and verified (0.29 Kbytes/sec)

Sat May 31 03:20:25 2008: Loaded debugee: D:\ProfessionalTools\IAR Systems\ARM\config\flashloader\ST\FlashSTM32F10x.out

Sat May 31 03:20:25 2008: Software reset was performed

Sat May 31 03:20:25 2008: Target reset

Sat May 31 03:20:31 2008: Non-zero or missing exit code.

So Flash Loader should be enabled to download data to flash?

But I found that the content of flash is unchanged after program.

Anyting wrong with my settings?

Check the log file of OpenOCD, there is no error, but IAR fails to enter into debug mode. I’ll try to fight out.

I download the flash manually thru command “flash write_image demo.bin 0x08000000 bin”, and sellect “Suppress Download” in download page, And the error is:

http://www.simonqian.com/download/temp/sim_err.JPG

If I sellect “Simulator” instead of “DBG Server”, It should be:

http://www.simonqian.com/download/temp/sim.JPG

Content of flash(first 16 bytes):00 20 00 20 DD 06 00 08 35 05 00 08 39 05 00 08

I read them manually:

mdw 0x08000000 4

0x08000000: 20002000 080006dd 08000535 08000539

mdw 0x0800043c 4

0x0800043c: f000b501 f000f82d 2101f863 f7ff2008

mdh 0x0800043c 8

0x0800043c: b501 f000 f82d f000 f863 2101 2008 f7ff

mdb 0x0800043c 16

0x0800043c: 01 b5 00 f0 2d f8 00 f0 63 f8 01 21 08 20 ff f7

So flash data read is OK. I found that when IAR stop on breakpoint, the PC is 0x0800043D, and it should be 0x0800043C.

I know in ARM chips, a odd PC means that it’s in THUMB mode, but IAR just take it as the real PC value?

But I use command “halt” when it’s running, the PC returned is EVEN.

I check the log file and found:

Debug: 670 109312 cortex_m3.c:363 cortex_m3_debug_entry(): entered debug state in core mode: Thread at PC 0x800043c, target->state: halted

Debug: 671 109312 target.c:724 target_call_event_callbacks(): target event 0

But I don’t know why IAR halt at 0x0800043D.

And the demo runs well, the correct LED blinks at the correct frequency, So I think the program in the flash is OK.

By the way:My OpenOCD tool is not the original supportted tools, I’ll try the verified tools such as USBprog later.

Openocd has a few tweaks inside to force gdb to support armv7 (cortex_m3).

One of these is setting bit0 of the pc, so it knows it is in thumb mode.

Unsure why your flash loader is not working, could try the following update:

http://www.st.com/stonline/products/sup … rm5.11.zip

Cheers

Spen

That updage doesn’t work.

I’ll try other settings.

As you said:

Openocd has a few tweaks inside to force gdb to support armv7 (cortex_m3).

One of these is setting bit0 of the pc, so it knows it is in thumb mode.

How to disable it, for maybe IAR take bit0 of pc as real value of pc. When I set a breakpoint at other address, it always stops at the address + 1.

Should not make any difference.

But if you want to disable it then you will have to rebuild openocd from source.

file armv7m.h and change following.

/* define for enabling armv7 gdb workarounds */

#if 0

#define ARMV7_GDB_HACKS

#endif

Cheers

Spen

It works if I disable it. Debug session stops at the right address.

And I can control the LEDs thru debug interface.

The Flash Loader also works well now.

BTW: The speed is raaaaaaaaaaaaaaaather slow.

I’ll optimize my STM32-based tools later for a better speed.

Sat May 31 22:09:28 2008: 1860 bytes downloaded into FLASH and verified (0.01 Kbytes/sec)

In function jlink_usb_message line 830:

Shouldn’t it be “if (0 == usb_in_buffer[result - 1])”?

no, sometimes the jlink will send the result in a single packet.

But ARMV7_GDB_HACKS do avoid OpenOCD functioning well.

Only with IAR, not with gdb that is its main use.

These hacks will be taken out when gdb fully supports armv7 arch.

codesourcery gdb supports the v7, but requires openocd to request support. This is being worked on.

Totally confused, I removed all the code in “#ifdef ARMV7_GDB_HACKS” in armv7m.c and cortex_m3.c, but OpenOCD crashed.

In log file(last lines):

Debug: 311 4968 gdb_server.c:1878 gdb_input_inner(): received packet: ‘m20000004,4’

Debug: 312 4968 gdb_server.c:1063 gdb_read_memory_packet(): addr: 0x20000004, len: 0x00000004

Debug: 313 4968 target.c:1048 target_read_buffer(): reading buffer of 4 byte at 0x20000004

Debug: 314 4968 gdb_server.c:1878 gdb_input_inner(): received packet: ‘g’

6 [main] openocd 13004 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)

Segmentation fault (core dumped)

the jlink driver is till work in progress, so may contain bugs.

Have a read of the BUGS file in the openocd root, it gives details of providing a backtrace.

Cheers

Spen

yes sorry i see what you mean now, i will commit the fix to svn.

Cheers

Spen