OpenOCD, STM32-P103 and ARM USB TINY problems

Development Boards MicroMod
1

After working on this for some time, I am able to connect to the STM32-P103

board through the ARM USB TINY form my Linux environment using the

configuration file attached and the command:

openocd -f stm32f10x-armusbtiny.cfg

I have attached the file for you to examine.

When I connect, the TINY responds with the following:

Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M

$URL: http://svn.berlios.de/svnroot/repos/ope … /openocd.c $

Info: options.c:50 configuration_output_handler(): jtag_speed: 10, 10

Info: options.c:50 configuration_output_handler(): Open On-Chip

Debugger 1.0

(2008-04-13-11:37) svn:568M

I presume that this means that it is working. I then started a telnet session

in another window, whereupon I received the following:

$ telnet localhost 4444

Trying 127.0.0.1…

Connected to localhost.

Escape character is ‘^]’.

Open On-Chip Debugger

This looks fine. I typed help, and received the help menu.

I then attempted to download a previously compiled program to the board

using the “load_image” command as follows:

load_image flash.bin 0x8000 ‘bin’

SWJ-DP STICKY ERROR

dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

SWJ-DP STICKY ERROR

dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Block write error address 0x8000, wcount 0x27d7

I also recompiled the program to produce an ihex file so that I could

see what the file contained (to make sure that it was valid), and tried to download it with

load_image flash.bin 0x8000 ‘ihex’

SWJ-DP STICKY ERROR

dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

SWJ-DP STICKY ERROR

dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Block write error address 0x10000, wcount 0x7d3

What is the problem? I don’t know how to solve it from here.

Best regards,

Peter

2

Oops. Forgot to attach the config file. Here it is.

Peter

#daemon configuration
telnet_port 4444
gdb_port 3333

# we use the ft2232 interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG TINY"
ft2232_layout olimex-jtag
ft2232_vid_pid 0x15ba 0x0004
# these settings come from openocd homepage.

#how fast should we talk to the jtag interface
#the numeb is a divisor for the speed -> 0 is the fastest possible
jtag_speed 40

jtag_nsrst_delay 200
jtag_ntrst_delay 200

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

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

#target configuration
#actually, we attatch to the <B5>C
#daemon_startup attach
#for flashing
daemon_startup reset



#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
#target arm7tdmi little run_and_halt 0 arm7tdmi-r4
#flash test
target cortex_m3 little run_and_halt 0
run_and_halt_time 0 30

working_area 0 0x20000000 0x4000 nobackup




#flash configuration
#flash bank <driver> <base> <size> <chip_width> <bus_width>
#flash bank at91sam7 0 0 0 0 <target#> (base, size, chip and bus_width are read from the target)
flash bank stm32x 0x08000000 0x00010000 0 0 0

# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open On-Chip Debugger

[/code]

3

Try using:

reset_config trst_and_srst

and reset_halt rather than run_and_halt

Cheers

Spen

4

Hi, Spen,

I get this response when I use “run_halt” and “reset_halt”:

Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M

$URL: http://svn.berlios.de/svnroot/repos/ope … /openocd.c $

Info: options.c:50 configuration_output_handler(): jtag_speed: 20, 20

Info: options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M

Error: jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined

Best regards,

Peter

5

Spen,

When I issue the command “flash probe 0” with telnet, I get:

flash probe 0

device id = 0x20006410

SWJ-DP STICKY ERROR

dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

flash size = 0kbytes

flash ‘stm32x’ found at 0x08000000

This says that the processor has no flash, but this processor is supposed to have 128kbytes starting at 0x08000000.

I have no isea about the SWJ-DP STICKY ERROR.

Regards,

Peter

6

An update:

I can download code to the RAM on the STM32F103 chip successfully. I still get the SWJ-DP STICKY ERROR message, however. The RAM contents appear to be correct.

Is there anything special that I must do to program the flash?

Regards,

Peter

7

I am using the following scripts in order to program the flash.

Configuration:

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003
jtag_speed 100

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

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

#target configuration
daemon_startup reset

#target <type> <startup mode>
target cortex_m3 little run_and_init 0
run_and_halt_time 0 30

working_area 0 0x20000000 16384 nobackup

#flash configuration
flash bank stm32x 0x08000000 0x00010000 0 0 0

Programming script:

halt
wait_halt
poll
flash probe 0
stm32x mass_erase 0
flash write_binary 0 ch.bin 0
reset run

regards,

Giovanni

8

Giovanni, what subversion revision are you using? I’ve been having very similar problems as Peter, and your configuration/script does not work for me.

However, I’ve played around with OpenOCD enough to notice that its support for the STM32 family is um, flaky, to put it mildly. Later revisions of OpenOCD have often introduced more problems than they solve in this regard.

I’ve tried three or four different revisions and always manage to find a few show-stopping bugs, such as incorrect values reported by “reg pc” (and presumably if you manipulate the “pc” manually, you aren’t actually manipulating the program counter), core dump upon “flash protect 0 0x7FF off”, incorrect values reported when using the mdw (memory display word) command, and the list goes on and on.

Best,

Leon

9

I do quite a lot on the stm32 and cortex_m3 support within openocd.

If you find bugs then a report would be good, as i find it very reliable.

Suggestions are always welcome.

Cheers

Spen

10

I will be posting bug reports, as soon as I start to sort everything out. Part of the problem is that I forget which version of OpenOCD I tried first, and the behaviors are rather inconsistent across versions.

For example, the “reg pc” bug I’m pretty sure has been fixed. It doesn’t work with the latest Ubuntu Multiverse package, or revision 555, but it does work with more recent versions. (At least that’s my impression.)

11

I am using build 247. a bit old but I am able to flash the device. I will try a more recent version tomorrow.

Giovanni

12

I bought another Olimex board, the STM32-103STK this time so that I would have a working board to start with (It displayed the demo software on startup).

I then tried to program it with Lanchon’s demo code that flashes a LED. That code was written for the STM32-H103, but the STM32-103STK board uses the same pin for the LED so it should at least flash the LED.

The good news is that unlike my previous board (see the first post above), this board reports that it has 128K flash at 0x08000000. The previous board reported 0kbytes.

Now the bad news.

The result of trying to program the new board is the following .Note that I use a FreeBSD system and so my make is gmake. The make compiled and linked successfully.

$ gmake flash
Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M
Info:    options.c:50 configuration_output_handler(): jtag_speed: 10, 10
Error:   jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined
Info:    target.c:237 target_init_handler(): executing reset script 'flash-bin.script'
Info:    stm32x.c:621 stm32x_probe(): device id = 0x20006410
Info:    stm32x.c:640 stm32x_probe(): flash size = 128kbytes
Info:    options.c:50 configuration_output_handler(): stm32x mass erase complete
Info:    options.c:50 configuration_output_handler(): wrote 40796 byte from file flash.bin in 3.682765s (10.817916 kb/s)
Info:    options.c:50 configuration_output_handler(): verified 40796 bytes in 1.019158s
Error:   jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined
Segmentation fault
gmake: *** [flash] Error 139

I made two modifications to Lanchon’s flash.script. My binary file is called flash.bin, so my write_image command is:

flash write_image flash.bin 0x08000000 bin

and I added a verify_image command to check the flash contents.

The above response of the system suggests that the flash programmed successfully, although this occurs about one try in 10, and always ends with a segmentation fault. Usually I get:

$ gmake flash
Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-04-13-11:37) svn:568M
Info:    options.c:50 configuration_output_handler(): jtag_speed: 10, 10
Error:   jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined
Info:    target.c:237 target_init_handler(): executing reset script 'flash-bin.script'
Info:    stm32x.c:621 stm32x_probe(): device id = 0x20006410
Info:    stm32x.c:640 stm32x_probe(): flash size = 128kbytes
Info:    options.c:50 configuration_output_handler(): stm32x mass erase complete
Info:    options.c:50 configuration_output_handler(): wrote 40796 byte from file flash.bin in 3.546419s (11.233823 kb/s)
Info:    options.c:50 configuration_output_handler(): checksum mismatch - attempting binary compare

where it hangs. Sometime I get a large number of error such as:

Warning: jtag.c:1197 jtag_check_value(): value captured during scan didn't pass the requested check: captured: 0x0b check_value: 0x01 check_mask: 0x0f
Warning: jtag.c:1157 jtag_read_buffer(): in_handler reported a failed check
Warning: jtag.c:1197 jtag_check_value(): value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x01 check_mask: 0x0f
Warning: jtag.c:1157 jtag_read_buffer(): in_handler reported a failed check
Warning: jtag.c:1197 jtag_check_value(): value captured during scan didn't pass t...

In no case does the LED flash.

My questions:

  1. Why is it so flaky? Do others have these problems, and if not, what am I doing wrong? How do you program the board?

  2. Can I be sure that when it says that the flash verified properly, that it is in fact correct?

  3. Why doesn’t the LED flash? I made no changes whatsoever to Lanchon’s source code.

Could someone please help me?

13

Openocd is going through quite a few changes as of late, so always try the latest from svn if you are having trouble.

Cheers

Spen

14

My Hardware:

Olimex ARM-USB-OCD Jtag

Olimex STM32-P103

My software:

Ubuntu 8.04 (32-bit x86)

GCC 4.2.3

libfdti-0.12 (compiled myself)

openocd rev 568 (compiled with: --enable-ft2232_libftdi --enable-usbprog)

The commands “stm32x lock 0” and “stm32x unlock 0” manipulate some bit in the target device. OpenOCD reads this bit at startup, and then reports the SWJ-DP error on a “flash probe 0” based on that, regardless of the actual state of the bit.

Once you get the device unlocked, attempting to removing protection on the flash banks causes core dumps:

“flash protect 0 0 0x1FFFF off”

However, re-entering “ocd” and running “flash info 0” reveals that OpenOCD crashed before the flash protection got turned off, not after.

And NTFreak, the commands “stm32x lock 0” and “stm32x unlock 0” dosn’t even work with newer revisions, starting sometime before revision 585, and continuing on to at least 623. OpenOCD needs to get quality assurance under control. Given the current state of the project, I will be leery about upgrading once I get something working.

15

huh. I must have actually been using version 585 at one point when I thought I was using 623, because “stm32x lock 0” and “stm32x unlock 0” work on revision 623.

The SWJ-DP sticky bug error I previously described is still present in 623, however, as well as the core dumpage.

Incidentially, while I’m a vastly better user of Linux than I am a user of Windows, I have tried this a little bit with Windows, too. I couldn’t even get the software on the CD to work.

16

I just tried a “load_image flash.bin 0x08000000 bin” command. It failed and now “flash probe 0” reports a SWJ-DP STICKY ERROR and says that the falsh size is 0kbytes. What have I done wrong? How do I get the flash back?

Best regards,

Peter

17

Could you provide hardware, openocd version, config/logs and commands used etc.

As much info is possible to help solve the problem.

Cheers

Spen

18

Spen,

The hardware is an Olimex STM32F103-STK board with a STM32F103RBT6 chip. This is a Cortex-M3 chip.

The OpenOCD version is openocd_local.exe - OpenOCD for Win32, based on SVN Version 555 (trunk) modified for Cortex-M3 by Spencer Oliver (you?). I found it at http://www.siwawi.arubi.uni-kl.de/avr_p … index.html

and used it because the site said that it worked.

The host system is a PC running Windows XP.

The commands that I issued were:

C:\mypath\to\openocd_m3\openocd_local -d 3 -l logfile.txt -f original-openocd.cfg

to launch openocd. In a second window I ran

telnet localhost 4444

and then issued

halt

wait_halt

flash info 0

flash probe 0

shutdown

OpenOCD reports that the chip has 0kbytes of flash. Earlier today, before I issued a “load_image flash.bin 0x08000000 bin”, a “flash info 0” reported the correct amount of flash, 128kbytes.

What happened? How do I fix it? How can I avoid it?

Is there a way to attach a file to a posting rather than inserting it as I have? I usually use FreeBSD so I am not really Windows savvy.

Best regards,

Peter

The config file “original-openocd.cfg”:

Open On-Chip Debugger

(c) 2005 by Dominic Rath

(snapshot r247 from SVN tree + giveio, no official release, compiled my mifi)

–help | -h display this help

–file | -f use configuration file

–debug | -d set debug level <0-3>

–log_output | -l redirect log output to file

daemon configuration

logging

#debug 3

default ports

telnet_port 4444

gdb_port 3333

daemon_startup reset

#gdb_flash_program enable

interface configuration

interface ft2232

#ft2232_device_desc “Olimex OpenOCD JTAG A”

ft2232_device_desc “Olimex OpenOCD JTAG TINY A”

ft2232_layout olimex-jtag

jtag_speed 10

jtag_nsrst_delay 100

jtag_ntrst_delay 100

reset_config trst_and_srst

scan chain configuration

jtag_device L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

jtag_device 5 0x1 0x1 0x1e

target configuration

target

target cortex_m3

target cortex_m3 little reset_halt 0

#target cortex_m3 little run_and_halt 0

run_and_halt_time <time_in_ms>

#run_and_halt_time 0 0

working_area <backup|nobackup>

working_area 0 0x20000000 0x5000 nobackup

flash bank <chip_width> <bus_width> [options]

flash bank stm32x 0 0

flash bank stm32x 0x08000000 0x20000 0 0 0

The logfile:

Debug: 6 16 command.c:383 command_run_line(): script original-openocd.cfg

Debug: 7 16 configuration.c:87 open_file_from_path(): opened original-openocd.cfg

Debug: 8 16 command.c:383 command_run_line(): telnet_port 4444

Debug: 9 16 command.c:383 command_run_line(): gdb_port 3333

Debug: 10 16 command.c:383 command_run_line(): daemon_startup reset

Info: 11 16 options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-04-09-14:00) svn:

Debug: 12 16 command.c:383 command_run_line(): interface ft2232

Debug: 13 16 command.c:383 command_run_line(): ft2232_device_desc “Olimex OpenOCD JTAG TINY A”

Debug: 14 16 command.c:383 command_run_line(): ft2232_layout olimex-jtag

Debug: 15 16 command.c:383 command_run_line(): jtag_speed 10

Debug: 16 16 jtag.c:1827 handle_jtag_speed_command(): handle jtag speed

Info: 17 16 options.c:50 configuration_output_handler(): jtag_speed: 10, 10

Debug: 18 16 command.c:383 command_run_line(): jtag_nsrst_delay 100

Debug: 19 16 command.c:383 command_run_line(): jtag_ntrst_delay 100

Debug: 20 16 command.c:383 command_run_line(): reset_config trst_and_srst

Debug: 21 16 command.c:383 command_run_line(): jtag_device 4 0x1 0xf 0xe

Debug: 22 16 command.c:383 command_run_line(): jtag_device 5 0x1 0x1 0x1e

Debug: 23 16 command.c:383 command_run_line(): target cortex_m3 little reset_halt 0

Debug: 24 16 command.c:383 command_run_line(): working_area 0 0x20000000 0x5000 nobackup

Debug: 25 16 command.c:383 command_run_line(): flash bank stm32x 0x08000000 0x20000 0 0 0

Debug: 26 16 command.c:383 command_run_line(): init

Debug: 27 16 jtag.c:1515 jtag_init_inner(): -

Debug: 28 16 ft2232.c:1330 ft2232_init_ftd2xx(): ‘ft2232’ interface using FTD2XX with ‘olimex-jtag’ layout (0403:6010)

Debug: 29 32 ft2232.c:1419 ft2232_init_ftd2xx(): current latency timer: 2

Debug: 30 32 ft2232.c:1766 olimex_jtag_init(): 80 08 1b

Debug: 31 32 ft2232.c:1809 olimex_jtag_init(): 82 09 0f

Debug: 32 32 ft2232.c:252 ft2232_speed(): 86 0a 00

Debug: 33 32 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 34 32 jtag.c:1275 jtag_reset_callback(): -

Debug: 35 32 jtag.c:1275 jtag_reset_callback(): -

Debug: 36 32 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 37 32 jtag.c:1275 jtag_reset_callback(): -

Debug: 38 32 jtag.c:1275 jtag_reset_callback(): -

Info: 39 32 jtag.c:1369 jtag_examine_chain(): JTAG device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)

Info: 40 32 jtag.c:1369 jtag_examine_chain(): JTAG device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)

Debug: 41 32 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 42 32 jtag.c:1275 jtag_reset_callback(): -

Debug: 43 32 jtag.c:1275 jtag_reset_callback(): -

Debug: 44 47 openocd.c:100 handle_init_command(): jtag init complete

Debug: 45 47 cortex_swjdp.c:945 ahbap_debugport_init():

Debug: 46 47 cortex_swjdp.c:986 ahbap_debugport_init(): AHB-AP ID Register 0x14770011, Debug ROM Address 0xe00ff003

Debug: 47 47 target.c:991 target_read_u32(): address: 0xe000ed00, value: 0x411fc231

Debug: 48 47 cortex_m3.c:1285 cortex_m3_init_target(): CORTEX-M3 processor detected

Debug: 49 47 cortex_m3.c:1286 cortex_m3_init_target(): cpuid: 0x411fc231

Debug: 50 47 target.c:991 target_read_u32(): address: 0xe000e004, value: 0x00000001

Debug: 51 47 target.c:991 target_read_u32(): address: 0xe000e100, value: 0x00000000

Debug: 52 47 cortex_m3.c:1294 cortex_m3_init_target(): interrupt enable[0] = 0x00000000

Debug: 53 47 target.c:991 target_read_u32(): address: 0xe000e104, value: 0x00000000

Debug: 54 47 cortex_m3.c:1294 cortex_m3_init_target(): interrupt enable[1] = 0x00000000

Debug: 55 63 target.c:991 target_read_u32(): address: 0xe0002000, value: 0x00000261

Debug: 56 63 cortex_m3.c:1309 cortex_m3_init_target(): FPB fpcr 0x261, numcode 6, numlit 2

Debug: 57 63 target.c:991 target_read_u32(): address: 0xe0001000, value: 0x40000000

Debug: 58 63 openocd.c:104 handle_init_command(): target init complete

Debug: 59 63 openocd.c:108 handle_init_command(): flash init complete

Debug: 60 63 openocd.c:112 handle_init_command(): NAND init complete

Debug: 61 63 openocd.c:116 handle_init_command(): pld init complete

Debug: 62 422 gdb_server.c:1961 gdb_init(): gdb service for target cortex_m3 at port 3333

Debug: 63 422 command.c:383 command_run_line(): reset

Debug: 64 422 target.c:1652 handle_reset_command(): -

Debug: 65 422 ft2232.c:252 ft2232_speed(): 86 0a 00

Debug: 66 422 jtag.c:1557 jtag_init_reset(): Trying to bring the JTAG controller to life by asserting TRST / tms

Debug: 67 422 jtag.c:982 jtag_add_reset(): SRST line released

Debug: 68 422 jtag.c:1001 jtag_add_reset(): TRST line asserted

Debug: 69 422 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 70 422 jtag.c:1275 jtag_reset_callback(): -

Debug: 71 422 jtag.c:1275 jtag_reset_callback(): -

Debug: 72 422 jtag.c:978 jtag_add_reset(): SRST line asserted

Debug: 73 422 jtag.c:1001 jtag_add_reset(): TRST line asserted

Debug: 74 422 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 75 422 jtag.c:1275 jtag_reset_callback(): -

Debug: 76 422 jtag.c:1275 jtag_reset_callback(): -

Debug: 77 422 jtag.c:978 jtag_add_reset(): SRST line asserted

Debug: 78 422 jtag.c:982 jtag_add_reset(): SRST line released

Debug: 79 422 ft2232.c:993 olimex_jtag_reset(): trst: 1, srst: 0, high_output: 0x00, high_direction: 0x0f

Debug: 80 532 ft2232.c:993 olimex_jtag_reset(): trst: 1, srst: 1, high_output: 0x02, high_direction: 0x0f

Debug: 81 532 ft2232.c:993 olimex_jtag_reset(): trst: 0, srst: 1, high_output: 0x03, high_direction: 0x0f

Debug: 82 641 ft2232.c:993 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x01, high_direction: 0x0f

Debug: 83 860 jtag.c:1515 jtag_init_inner(): -

Debug: 84 860 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 85 860 jtag.c:1275 jtag_reset_callback(): -

Debug: 86 860 jtag.c:1275 jtag_reset_callback(): -

Info: 87 860 jtag.c:1369 jtag_examine_chain(): JTAG device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)

Info: 88 860 jtag.c:1369 jtag_examine_chain(): JTAG device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)

Debug: 89 860 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 90 860 jtag.c:1275 jtag_reset_callback(): -

Debug: 91 860 jtag.c:1275 jtag_reset_callback(): -

Debug: 92 860 cortex_m3.c:705 cortex_m3_assert_reset(): target->state: unknown

Debug: 93 860 cortex_m3.c:532 cortex_m3_prepare_reset_halt(): dcb_dhcsr 0x3000f, dcb_demcr 0x1000501,

Error: 94 860 jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined

Debug: 95 860 jtag.c:978 jtag_add_reset(): SRST line asserted

Debug: 96 860 jtag.c:1001 jtag_add_reset(): TRST line asserted

Debug: 97 860 jtag.c:312 jtag_call_event_callbacks(): jtag event: JTAG controller reset(tms or TRST)

Debug: 98 860 jtag.c:1275 jtag_reset_callback(): -

Debug: 99 860 jtag.c:1275 jtag_reset_callback(): -

Debug: 100 860 jtag.c:978 jtag_add_reset(): SRST line asserted

Debug: 101 860 ft2232.c:993 olimex_jtag_reset(): trst: 1, srst: 1, high_output: 0x02, high_direction: 0x0f

Debug: 102 875 ft2232.c:993 olimex_jtag_reset(): trst: 0, srst: 1, high_output: 0x03, high_direction: 0x0f

Debug: 103 1047 cortex_m3.c:428 cortex_m3_halt(): target->state: reset

Debug: 104 1047 cortex_m3.c:764 cortex_m3_deassert_reset(): target->state: reset

Debug: 105 1047 jtag.c:982 jtag_add_reset(): SRST line released

Debug: 106 1047 ft2232.c:993 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x01, high_direction: 0x0f

Debug: 107 1266 target.c:357 target_process_reset(): Waiting for halted stated as approperiate

Debug: 108 1266 cortex_m3.c:383 cortex_m3_poll(): Exit from reset with dcb_dhcsr 0x3000f

Debug: 109 1266 cortex_m3.c:173 cortex_m3_endreset_event(): DCB_DEMCR = 0x01000501

Debug: 110 1266 target.c:1044 target_write_u32(): address: 0xe0002000, value: 0x00000003

Debug: 111 1266 target.c:1044 target_write_u32(): address: 0xe0002008, value: 0x00000000

Debug: 112 1266 target.c:1044 target_write_u32(): address: 0xe000200c, value: 0x00000000

Debug: 113 1282 target.c:1044 target_write_u32(): address: 0xe0002010, value: 0x00000000

Debug: 114 1282 target.c:1044 target_write_u32(): address: 0xe0002014, value: 0x00000000

Debug: 115 1282 target.c:1044 target_write_u32(): address: 0xe0002018, value: 0x00000000

Debug: 116 1282 target.c:1044 target_write_u32(): address: 0xe000201c, value: 0x00000000

Debug: 117 1282 target.c:1044 target_write_u32(): address: 0xe0002020, value: 0x00000000

Debug: 118 1282 target.c:1044 target_write_u32(): address: 0xe0002024, value: 0x00000000

Debug: 119 1282 target.c:1044 target_write_u32(): address: 0xe0001020, value: 0x00000000

Debug: 120 1282 target.c:1044 target_write_u32(): address: 0xe0001024, value: 0x00000000

Debug: 121 1297 target.c:1044 target_write_u32(): address: 0xe0001028, value: 0x00000000

Debug: 122 1297 target.c:1044 target_write_u32(): address: 0xe0001030, value: 0x00000000

Debug: 123 1297 target.c:1044 target_write_u32(): address: 0xe0001034, value: 0x00000000

Debug: 124 1297 target.c:1044 target_write_u32(): address: 0xe0001038, value: 0x00000000

Debug: 125 1297 target.c:1044 target_write_u32(): address: 0xe0001040, value: 0x00000000

Debug: 126 1297 target.c:1044 target_write_u32(): address: 0xe0001044, value: 0x00000000

Debug: 127 1297 target.c:1044 target_write_u32(): address: 0xe0001048, value: 0x00000000

Debug: 128 1313 target.c:1044 target_write_u32(): address: 0xe0001050, value: 0x00000000

Debug: 129 1313 target.c:1044 target_write_u32(): address: 0xe0001054, value: 0x00000000

Debug: 130 1313 target.c:1044 target_write_u32(): address: 0xe0001058, value: 0x00000000

Debug: 131 1313 cortex_m3.c:299 cortex_m3_debug_entry():

Debug: 132 1313 cortex_m3.c:105 cortex_m3_clear_halt(): NVIC_DFSR 0x8

Debug: 133 1328 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 0 value 0x0

Debug: 134 1328 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 1 value 0xfffefffc

Debug: 135 1344 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 2 value 0x18c56400

Debug: 136 1344 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 3 value 0x481ed8e3

Debug: 137 1344 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 4 value 0xdbfffdfb

Debug: 138 1360 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 5 value 0xa286ffff

Debug: 139 1360 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 6 value 0x156790ec

Debug: 140 1360 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 7 value 0xa8ab1c4

Debug: 141 1375 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 8 value 0xfeebfffb

Debug: 142 1375 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 9 value 0xfffdf7dd

Debug: 143 1391 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 10 value 0x523f4d10

Debug: 144 1391 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 11 value 0x2056b1d0

Debug: 145 1391 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 12 value 0xffdefff1

Debug: 146 1407 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 13 value 0xfffffffc

Debug: 147 1407 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 14 value 0xffffffff

Debug: 148 1422 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 15 value 0xfffffffe

Debug: 149 1422 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 16 value 0x1000000

Debug: 150 1422 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 17 value 0xfffffffc

Debug: 151 1438 cortex_m3.c:1116 cortex_m3_load_core_reg_u32(): load from core reg 18 value 0xc361700

Debug: 152 1438 cortex_m3.c:121 cortex_m3_single_step_core():

Debug: 153 1453 cortex_m3.c:105 cortex_m3_clear_halt(): NVIC_DFSR 0x1

Debug: 154 1453 cortex_m3.c:1136 cortex_m3_load_core_reg_u32(): load from special reg 16 value 0x0

Debug: 155 1469 cortex_m3.c:121 cortex_m3_single_step_core():

Debug: 156 1469 cortex_m3.c:105 cortex_m3_clear_halt(): NVIC_DFSR 0x1

Debug: 157 1485 cortex_m3.c:1136 cortex_m3_load_core_reg_u32(): load from special reg 17 value 0x0

Debug: 158 1485 cortex_m3.c:121 cortex_m3_single_step_core():

Debug: 159 1485 cortex_m3.c:105 cortex_m3_clear_halt(): NVIC_DFSR 0x1

Debug: 160 1500 cortex_m3.c:1136 cortex_m3_load_core_reg_u32(): load from special reg 19 value 0x0

Debug: 161 1516 cortex_m3.c:121 cortex_m3_single_step_core():

Debug: 162 1516 cortex_m3.c:105 cortex_m3_clear_halt(): NVIC_DFSR 0x1

Debug: 163 1516 cortex_m3.c:1136 cortex_m3_load_core_reg_u32(): load from special reg 20 value 0x0

Debug: 164 1516 cortex_m3.c:342 cortex_m3_debug_entry(): entered debug state in core mode: Thread at PC 0xfffffffe, target->state: halted

Debug: 165 1516 target.c:585 target_call_event_callbacks(): target event 0

Debug: 166 1516 cortex_m3.c:417 cortex_m3_poll(): dcb_dhcsr 0x3000f, nvic_dfsr 0x0, target->state: halted

Debug: 167 1516 target.c:371 target_process_reset(): Polling target

Debug: 168 1532 cortex_m3.c:417 cortex_m3_poll(): dcb_dhcsr 0x103000f, nvic_dfsr 0x0, target->state: halted

Debug: 169 1532 ft2232.c:252 ft2232_speed(): 86 0a 00

Info: 170 11219 server.c:78 add_connection(): accepting ‘telnet’ connection from 0

Debug: 171 14032 command.c:383 command_run_line(): halt

Debug: 172 14032 target.c:1624 handle_halt_command(): -

Debug: 173 14032 cortex_m3.c:428 cortex_m3_halt(): target->state: halted

Debug: 174 14032 cortex_m3.c:432 cortex_m3_halt(): target was already halted

Debug: 175 14032 cortex_m3.c:417 cortex_m3_poll(): dcb_dhcsr 0x3000f, nvic_dfsr 0x0, target->state: halted

Debug: 176 18141 command.c:383 command_run_line(): wait_halt

Debug: 177 18141 cortex_m3.c:417 cortex_m3_poll(): dcb_dhcsr 0x3000f, nvic_dfsr 0x0, target->state: halted

Debug: 178 23016 command.c:383 command_run_line(): flash info 0

Debug: 179 23016 target.c:991 target_read_u32(): address: 0xe0042000, value: 0x20006410

Info: 180 23016 stm32x.c:622 stm32x_probe(): device id = 0x20006410

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

Error: 182 23016 cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR

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

Error: 184 23032 cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Debug: 185 23032 target.c:1016 target_read_u16(): address: 0x1ffff7e0 failed

Info: 186 23032 stm32x.c:641 stm32x_probe(): flash size = 0kbytes

Debug: 187 28047 command.c:383 command_run_line(): flash probe 0

Debug: 188 28047 target.c:991 target_read_u32(): address: 0xe0042000, value: 0x20006410

Info: 189 28047 stm32x.c:622 stm32x_probe(): device id = 0x20006410

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

Error: 191 28047 cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR

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

Error: 193 28063 cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8

Debug: 194 28063 target.c:1016 target_read_u16(): address: 0x1ffff7e0 failed

Info: 195 28063 stm32x.c:641 stm32x_probe(): flash size = 0kbytes

Debug: 196 32641 command.c:383 command_run_line(): shutdown

Debug: 197 32641 command.c:340 find_and_run_command(): Command failed with error code -600

Info: 198 32641 server.c:395 server_loop(): dropped ‘telnet’ connection

[/code]

19

Spen, the problem is not the hardware, it’s the software. Look at my posts above. These bugs that I’ve described are not fixed in the latest release.

Peter, I have managed to flash my board. You need to run “stm32x unlock 0”. Then you must restart OpenOCD in order to re-read the state on the board. You’ll be able to “flash probe 0” after the restart. Then “flash write_bank 0 main.bin 0” and “reset”.

I have written a (long) post about how to get this working, step-by-step on linux, but I haven’t been able to post it, due to an “internal server error” on this webserver.

20

This issue is caused by the flash probe it is failing - unsure why.

You are using revB silicon, so should work fine. I will look into it.

Cheers

Spen