Re: [Openocd-development] [PATCH] etm: print something when trace buffer empty
Øyvind Harboe wrote: What tool would you want to feed this trace data into btw? I was thinking it would be possible to modify the gdb server to allow stepping through trace data. I don't know.. some kind of gdb hookup might be nice for its symbol resolution, not sure how that would work. Really though, I just had a weird crash bug, since tracked down by other means, and was hoping to use the ETM to tell me where it came from. I don't know much at all about using the ETM, I'm just some poor sap who tried to and failed :) -- 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
Re: [Openocd-development] [PATCH] etm: print something when trace buffer empty
On Mon, May 31, 2010 at 9:13 AM, Jon Povey jon.po...@racelogic.co.uk wrote: Øyvind Harboe wrote: What tool would you want to feed this trace data into btw? I was thinking it would be possible to modify the gdb server to allow stepping through trace data. I don't know.. some kind of gdb hookup might be nice for its symbol resolution, not sure how that would work. Really though, I just had a weird crash bug, since tracked down by other means, and was hoping to use the ETM to tell me where it came from. I don't know much at all about using the ETM, I'm just some poor sap who tried to and failed :) That's my understanding of ETM/ETB as well... It's something you turn to when normal debugging means don't give you answers effectively anymore. The problem is that you also then need to invest in learning a new skillset to solve a specific bug. The nice thing about hooking ETM/ETB up to GDB would be that you could use your existing skills tools to view the ETM/ETB data. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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] OpenOCD
Dne Po 31. května 2010 09:49:18 Mars Steeve napsal(a): Hi Marek, I finally received my JTAG KEY Tiny and successfully compiled OpenOCD 0.4.0 with your patches. Unfortunately, I'm unable to flash or debug my board (colibri pxa320), the CPU is never halted. I post the result of reset halt. $ openocd -f interface/jtagkey-tiny.cfg -f board/colibri_pxa320.cfg reset halt JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009, part: 0xe642, ver: 0x7) Bad value '00' captured during DR or IR scan: check_value: 0x02 check_mask: 0x07 JTAG error while writing DCSR Bad value '00' captured during DR or IR scan: check_value: 0x02 check_mask: 0x06 JTAG error while reading TX error while polling TX register, reset CPU target state: halted target halted in ARM state due to target-not-halted, current mode: User cpsr: 0x pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled Thanks for your help! I saw this with my vpaclink on Zylonite PXA320. By using the homemade JTAGkey, it worked. I assume there's a problem with not enough drive strength on some JTAG adapters. Maybe try adding a buffer past the adapter. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD
Dne Po 31. května 2010 16:19:23 Mars Steeve napsal(a): I don't think that it's an electrical problem, the jtagkey works fine with ColibriLoader software, except that it cannot upload more than 128KB (unable to flash an entire u-boot with flash support). I saw this with my vpaclink on Zylonite PXA320. By using the homemade JTAGkey, it worked. I assume there's a problem with not enough drive strength on some JTAG adapters. Maybe try adding a buffer past the adapter. (just a note, please stop top-posting, post under the text you reply to) Anyway ... Then we probably have an OpenOCD bug here. Maybe you can try tinkering with the jtag_nsrst_delay or reset_config stuff ? I CCed more involved people. ___ 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
[Openocd-development] About CortexM0 support
I tried to add support to LPC11XX in vsprog. LPC11XX is CortexM0 from NXP. There is the differences: 1. different ID (of course) 2. tar_autoincr_block is 1K instead of CortexM3's 4K 3. fewer asm code can be used in flash loader Thumb2 of CortexM0 is subset of thumb2 of CortexM3. If anyone tries to add it to OpenOCD, he can test these differences. -- Best Regards, SimonQian http://www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
