Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
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 + 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, 0xf021 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 0xf001 Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 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 0xf001 Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfff8, count 0x1 At a first glance, it seems fairly normal. The failed accesses to 0xfffX 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: 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 0x800 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: 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
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, Jun 7, 2010 at 5:21 PM, Kenan Özdemir gla...@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: pc: 0x2040 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 (0x0800) and the reset vector in the second (0x0804). /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
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: gla...@hotmail.de To: openocd-development@lists.berlios.de Date: Mon, 31 May 2010 13:13:05 + 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, 0xf021 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 0xf001 Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 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 0xf001 Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfff8, 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: 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 0x800 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!___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Tue, Jun 1, 2010 at 5:01 PM, Kenan Özdemir gla...@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. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[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, 0xf021 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 0xf001 Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 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 0xf001 Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfff8, 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: 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 0x800 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!___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
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, 0xf021 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 0xf001 Error: 3400 39766 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Debug: 3401 39781 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 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 0xf001 Error: 3404 39781 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0xfffc Warn : 3405 39781 arm_adi_v5.c:989 mem_ap_read_buf_u32(): Block read error address 0xfff8, count 0x1 At a first glance, it seems fairly normal. The failed accesses to 0xfffX 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: 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 0x800 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: 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
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!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin freddie_cho...@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? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
On Mon, May 31, 2010 at 10:43 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Mon, May 31, 2010 at 10:35 PM, Freddie Chopin freddie_cho...@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 : (gbd) load (gbd) mon gdb_sync (gbd) stepi (gbd) info reg ... sp 0xfffc 0xfffc lr 0x 4294967295 pc 0x80002dd0x80002dd 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) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 JTAG-DP STICKY ERROR
Andreas Fritiofson wrote: On Mon, May 31, 2010 at 3:13 PM, Kenan Özdemir gla...@hotmail.de wrote: target remote localhost: 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 jon.po...@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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
