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: gla...@hotmail.de
To: andreas.fritiof...@gmail.com
Date: Mon, 7 Jun 2010 07:48:28 +0000
CC: openocd-development@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: andreas.fritiof...@gmail.com
> To: gla...@hotmail.de
> CC: openocd-development@lists.berlios.de
>
> On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir <gla...@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!_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
