[Openocd-development] STM32 JTAG-DP STICKY ERROR

[Kenan Özdemir]

Hi Guys,

I have the following problem..

Each time I try to Debug I got this Error Message it is out of my logfile..

Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf0000021
Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR
Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf0000001
Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf0000021
Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR
Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf0000001
Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfffffff8, count 0x1

I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse, OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd 0.4.0

here are my GDB commands:

target remote localhost:3333
monitor reset halt
monitor stm32x mass_erase 0
monitor stm32x options_read 0
monitor stm32x unlock 0
monitor reset
monitor flash write_image main.bin 0x8000000 bin
file main.out
load main.out
break main

I try to solve this problem for weeks.. thx for any help


_________________________________________________________________
http://redirect.gimas.net/?n=M1005xGreetings2
Machen Sie anderen eine digitale Geburtstagsfreude: kostenlos!

[Andreas Fritiofson]

On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir <***@hotmail.de> wrote:
> Hi Guys,
>
> I have the following problem..
>
> Each time I try to Debug I got this Error Message it is out of my logfile..
>
> Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
> CTRL/STAT error, 0xf0000021
> Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
> STICKY ERROR
> Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
> CTRL/STAT 0xf0000001
> Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
> 0x23000052, MEM_AP_TAR 0xfffffffc
> Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
> CTRL/STAT error, 0xf0000021
> Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
> STICKY ERROR
> Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
> CTRL/STAT 0xf0000001
> Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
> 0x23000052, MEM_AP_TAR 0xfffffffc
> Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error
> address 0xfffffff8, count 0x1

At a first glance, it seems fairly normal. The failed accesses to
0xfffffffX are because GDB tries to backtrace through the stack frames
as far as it goes. Sooner or later it will reach one with the special
exception return value and stop because it can't read memory there.

I assume debugging isn't working for you (and not just the phony error
message nagging you)? What are the symptoms? Any other error messages?

> I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse,
> OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd
> 0.4.0

You should be aware of a bug in 0.4.0 causing the first debug session,
after OpenOCD has been started, to fail if the target is running when
GDB connects. It is fixed in recent git and can be worked around in
0.4.0 by either doing 'reset init' in a gdb-attach event handler, or
adding -c init -c 'reset init' to the command line when starting
OpenOCD.

>
> here are my GDB commands:
>
> target remote localhost:3333
> monitor reset halt
> monitor stm32x mass_erase 0
> monitor stm32x options_read 0
> monitor stm32x unlock 0
> monitor reset
> monitor flash write_image  main.bin 0x8000000 bin
> file main.out
> load main.out
> break main

This looks a bit strange. Nowadays, 'reset init' seems to be preferred
over 'reset halt'. I don't really know the difference but feel it
works better. The 'flash write_image' is superfluous since you later
tell GDB to do a 'load'. Skip the 'flash write_image' and let GDB
handle the flash programming. Also, I believe a second 'reset init' is
needed right after the load in order to update the initial SP and PC
from the newly loaded image. The 'mass_erase' is not needed, unless
you want to clear unused areas of flash, since the GDB load will erase
flash on a page by page basis. The 'unlock' is of course only
necessary if you have previously activated the readout protection. You
could make a separate script to unlock protected chips instead of
doing it each debug session.

My GDB initialization looks something like this (out of my head):

target remote localhost:3333
monitor reset init
load (if GDB has been told on the command line which executable to
debug, there's no need to specify a file here)
monitor reset init
tbreak main
continue

/Andreas

[Freddie Chopin]

On 2010-05-31 21:59, Andreas Fritiofson wrote:
> Also, I believe a second 'reset init' is
> needed right after the load in order to update the initial SP and PC
> from the newly loaded image.

It's not.

4\/3!!

[Andreas Fritiofson]

On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin <***@op.pl> wrote:
> On 2010-05-31 21:59, Andreas Fritiofson wrote:
>>
>> Also, I believe a second 'reset init' is
>> needed right after the load in order to update the initial SP and PC
>> from the newly loaded image.
>
> It's not.
>

Then what sets it?

[Andreas Fritiofson]

On Mon, May 31, 2010 at 10:43 PM, Andreas Fritiofson
<***@gmail.com> wrote:
> On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin <***@op.pl> wrote:
>> On 2010-05-31 21:59, Andreas Fritiofson wrote:
>>>
>>> Also, I believe a second 'reset init' is
>>> needed right after the load in order to update the initial SP and PC
>>> from the newly loaded image.
>>
>> It's not.
>>
>
> Then what sets it?
>

Just tried it:

oocd:
> stm32x mass_erase 0
> reset init

gdb:
(gbd) tar rem :3333
(gbd) load
(gbd) mon gdb_sync
(gbd) stepi
(gbd) info reg
...
sp 0xfffffffc 0xfffffffc
lr 0xffffffff 4294967295
pc 0x80002dd 0x80002dd <Reset_Handler>

So the PC is set up by GDB (assuming the entry point has been set
correctly in the elf-file) but nothing touches the stack pointer. And
sure enough:

(gdb) stepi
-> target is off to infinity and beyond (first instruction pushes some
registers)

[Kenan Özdemir]

So I did some changes on my GDB commands as you recommended me. But I have still the same errors. I will attach my logfile, makefile and my linker script just in case you could find an error and help me out.

This is how I try to work:
1) run openOCD
2) run arm-none-eabi-gdb

I can't even start debugging, the because I get this message: Program received signal SIGINT, Interrupt.

Regards,
Kenan

> Date: Mon, 31 May 2010 21:59:13 +0200
> Subject: Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
> From: ***@gmail.com
> To: ***@hotmail.de
> CC: openocd-***@lists.berlios.de
>
> On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir <***@hotmail.de> wrote:
> > Hi Guys,
> >
> > I have the following problem..
> >
> > Each time I try to Debug I got this Error Message it is out of my logfile..
> >
> > Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT error, 0xf0000021
> > Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
> > STICKY ERROR
> > Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT 0xf0000001
> > Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
> > 0x23000052, MEM_AP_TAR 0xfffffffc
> > Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT error, 0xf0000021
> > Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
> > STICKY ERROR
> > Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT 0xf0000001
> > Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
> > 0x23000052, MEM_AP_TAR 0xfffffffc
> > Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error
> > address 0xfffffff8, count 0x1
>
> At a first glance, it seems fairly normal. The failed accesses to
> 0xfffffffX are because GDB tries to backtrace through the stack frames
> as far as it goes. Sooner or later it will reach one with the special
> exception return value and stop because it can't read memory there.
>
> I assume debugging isn't working for you (and not just the phony error
> message nagging you)? What are the symptoms? Any other error messages?
>
> > I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse,
> > OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd
> > 0.4.0
>
> You should be aware of a bug in 0.4.0 causing the first debug session,
> after OpenOCD has been started, to fail if the target is running when
> GDB connects. It is fixed in recent git and can be worked around in
> 0.4.0 by either doing 'reset init' in a gdb-attach event handler, or
> adding -c init -c 'reset init' to the command line when starting
> OpenOCD.
>
> >
> > here are my GDB commands:
> >
> > target remote localhost:3333
> > monitor reset halt
> > monitor stm32x mass_erase 0
> > monitor stm32x options_read 0
> > monitor stm32x unlock 0
> > monitor reset
> > monitor flash write_image main.bin 0x8000000 bin
> > file main.out
> > load main.out
> > break main
>
> This looks a bit strange. Nowadays, 'reset init' seems to be preferred
> over 'reset halt'. I don't really know the difference but feel it
> works better. The 'flash write_image' is superfluous since you later
> tell GDB to do a 'load'. Skip the 'flash write_image' and let GDB
> handle the flash programming. Also, I believe a second 'reset init' is
> needed right after the load in order to update the initial SP and PC
> from the newly loaded image. The 'mass_erase' is not needed, unless
> you want to clear unused areas of flash, since the GDB load will erase
> flash on a page by page basis. The 'unlock' is of course only
> necessary if you have previously activated the readout protection. You
> could make a separate script to unlock protected chips instead of
> doing it each debug session.
>
> My GDB initialization looks something like this (out of my head):
>
> target remote localhost:3333
> monitor reset init
> load (if GDB has been told on the command line which executable to
> debug, there's no need to specify a file here)
> monitor reset init
> tbreak main
> continue
>
> /Andreas

_________________________________________________________________
http://redirect.gimas.net/?n=M1006xHMTL4
Künftig E-Mails über Hotmail ohne Werbung versenden!

[Kenan Özdemir]

I figured out, that the SIGINT signal was caused by an string function.

There is a memset in the tskTCB *prvAllocateTCBAndStack(...) function in task.c and if I comment it the problem is "solved"..
till the next SIGINT is caused by strncpy in void prvInitialiseTCBVariables(...) also in task.c

It looks like that there is something missing in my configurations.. :) but what?!

Kenan


From: ***@hotmail.de
To: ***@gmail.com
Date: Mon, 7 Jun 2010 07:48:28 +0000
CC: openocd-***@lists.berlios.de
Subject: Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR








So I did some changes on my GDB commands as you recommended me. But I have still the same errors. I will attach my logfile, makefile and my linker script just in case you could find an error and help me out.

This is how I try to work:
1) run openOCD
2) run arm-none-eabi-gdb

I can't even start debugging, the because I get this message: Program received signal SIGINT, Interrupt.

Regards,
Kenan

> Date: Mon, 31 May 2010 21:59:13 +0200
> Subject: Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
> From: ***@gmail.com
> To: ***@hotmail.de
> CC: openocd-***@lists.berlios.de
>
> On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir <***@hotmail.de> wrote:
> > Hi Guys,
> >
> > I have the following problem..
> >
> > Each time I try to Debug I got this Error Message it is out of my logfile..
> >
> > Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT error, 0xf0000021
> > Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
> > STICKY ERROR
> > Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT 0xf0000001
> > Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
> > 0x23000052, MEM_AP_TAR 0xfffffffc
> > Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT error, 0xf0000021
> > Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
> > STICKY ERROR
> > Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
> > CTRL/STAT 0xf0000001
> > Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
> > 0x23000052, MEM_AP_TAR 0xfffffffc
> > Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error
> > address 0xfffffff8, count 0x1
>
> At a first glance, it seems fairly normal. The failed accesses to
> 0xfffffffX are because GDB tries to backtrace through the stack frames
> as far as it goes. Sooner or later it will reach one with the special
> exception return value and stop because it can't read memory there.
>
> I assume debugging isn't working for you (and not just the phony error
> message nagging you)? What are the symptoms? Any other error messages?
>
> > I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse,
> > OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd
> > 0.4.0
>
> You should be aware of a bug in 0.4.0 causing the first debug session,
> after OpenOCD has been started, to fail if the target is running when
> GDB connects. It is fixed in recent git and can be worked around in
> 0.4.0 by either doing 'reset init' in a gdb-attach event handler, or
> adding -c init -c 'reset init' to the command line when starting
> OpenOCD.
>
> >
> > here are my GDB commands:
> >
> > target remote localhost:3333
> > monitor reset halt
> > monitor stm32x mass_erase 0
> > monitor stm32x options_read 0
> > monitor stm32x unlock 0
> > monitor reset
> > monitor flash write_image main.bin 0x8000000 bin
> > file main.out
> > load main.out
> > break main
>
> This looks a bit strange. Nowadays, 'reset init' seems to be preferred
> over 'reset halt'. I don't really know the difference but feel it
> works better. The 'flash write_image' is superfluous since you later
> tell GDB to do a 'load'. Skip the 'flash write_image' and let GDB
> handle the flash programming. Also, I believe a second 'reset init' is
> needed right after the load in order to update the initial SP and PC
> from the newly loaded image. The 'mass_erase' is not needed, unless
> you want to clear unused areas of flash, since the GDB load will erase
> flash on a page by page basis. The 'unlock' is of course only
> necessary if you have previously activated the readout protection. You
> could make a separate script to unlock protected chips instead of
> doing it each debug session.
>
> My GDB initialization looks something like this (out of my head):
>
> target remote localhost:3333
> monitor reset init
> load (if GDB has been told on the command line which executable to
> debug, there's no need to specify a file here)
> monitor reset init
> tbreak main
> continue
>
> /Andreas

Künftig E-Mails über Hotmail ohne Werbung versenden!
_________________________________________________________________
http://redirect.gimas.net/?n=M1006xHm2
Entdecken Sie die tollen neuen Funktionen von Hotmail!

[Andreas Fritiofson]

On Mon, Jun 7, 2010 at 5:21 PM, Kenan Özdemir <***@hotmail.de> wrote:
>
> I figured out, that the SIGINT signal was caused by an string function.
>
> There is a memset in the tskTCB *prvAllocateTCBAndStack(...) function in
> task.c and if I comment it the problem is "solved"..
> till the next SIGINT is caused by strncpy in void
> prvInitialiseTCBVariables(...) also in task.c
>
> It looks like that there is something missing in my configurations.. :) but
> what?!
>

User : 823 58626 armv7m.c:489 armv7m_arch_state(): target halted due
to debug-request, current mode: Thread

xPSR: 00000000 pc: 0x20000040 msp: 0x08002e90

This looks really wrong just after a reset. Executing from RAM with
stack pointer in flash... Check your vector table. It should have the
stack pointer in the first slot (0x08000000) and the reset vector in
the second (0x08000004).

/Andreas

[Jon Povey]

Andreas Fritiofson wrote:
> On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir <***@hotmail.de>
> wrote:

>> target remote localhost:3333
>> monitor reset halt

> This looks a bit strange. Nowadays, 'reset init' seems to be preferred
> over 'reset halt'. I don't really know the difference but feel it
> works better.

AFAIK the difference is that 'reset init' does the same as 'reset halt', then runs the reset-init event handler, which may be defined for your board to do things like setup PLLs, DRAM controller, pin muxing, etc. like a basic bootloader.
This is helper stuff as out of reset off-chip DRAM is probably inaccessible.

--
Jon Povey
***@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

[Kenan Özdemir]

This is only a part of the logfile.. I got more error messages like that, and each time I got also a SIGINT signal while debugging..
So how would you recommend me to solve that problem? Is it maybe the linker script where I have to do some changes?
Thx for your help

From: ***@hotmail.de
To: openocd-***@lists.berlios.de
Date: Mon, 31 May 2010 13:13:05 +0000
Subject: [Openocd-development] STM32 JTAG-DP STICKY ERROR








Hi Guys,

I have the following problem..

Each time I try to Debug I got this Error Message it is out of my logfile..

Debug: 3397 39766 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf0000021
Error: 3398 39766 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR
Debug: 3399 39766 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf0000001
Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf0000021
Error: 3402 39781 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR
Debug: 3403 39781 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf0000001
Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfffffff8, count 0x1

I'm using the Stm32-p103 board from Olminex with the Cortex M3, Eclipse, OpenOCD 0.4.0 and the standard config files for stm32 supported by oocd 0.4.0

here are my GDB commands:

target remote localhost:3333
monitor reset halt
monitor stm32x mass_erase 0
monitor stm32x options_read 0
monitor stm32x unlock 0
monitor reset
monitor flash write_image main.bin 0x8000000 bin
file main.out
load main.out
break main

I try to solve this problem for weeks.. thx for any help


Machen Sie anderen eine digitale Geburtstagsfreude: kostenlos!
_________________________________________________________________
http://redirect.gimas.net/?n=M1005xWin72
Windows 7 - Alles was Du brauchst und noch viel mehr!

[Andreas Fritiofson]

On Tue, Jun 1, 2010 at 5:01 PM, Kenan Özdemir <***@hotmail.de> wrote:
> This is only a part of the logfile.. I got more error messages like that,
> and each time I got also a SIGINT signal while debugging..
> So how would you recommend me to solve that problem? Is it maybe the linker
> script where I have to do some changes?
> Thx for your help
>

Start by fixing your gdbinit oddities. Then post the complete log
file, from a "minimal" debug session to reduce the noise, together
with a more detailed description of actual behavior.