Re: [Openocd-development] STM32 core debug reset problem
On 30/10/2010 09:20, Chris Jones wrote: On 30/10/2010 00:15, Andreas Fritiofson wrote: On Fri, Oct 29, 2010 at 8:58 PM, Chris Jonesch...@martin-jones.com wrote: But there's a way of breaking it semi-permanently. The application on the STM32 is one which spends most of its time with the CPU in Stop mode, waking up periodically (about every 12ms) via an RTC interrupt to do some processing. If I attempt to start OpenOCD while the microcontroller is stopping and running like this, I get messages which say, Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG hardware is clearly working to some extent. The whole JTAG system appears to be then stuck in this state. Restarting OpenOCD, doing a hardware system reset on the microcontroller, unplugging everything including the JTAG dongle and its USB interface, all make no difference. I've even tried exercising the JTAG port using another application (XJTAG) though this only does boundary scan testing and doesn't play with the ARM debug TAP. Though boundary scan works fine. The only thing which fixes the problem is power-cycling the STM32 chip itself. I note from its documentation and the ARM Cortex-M3 TRM that some parts of the core debug unit are only reset at power up, not in response to a system reset. The device has no TRST pin. However, this board is going to be permanently moulded into a plastic lump with a battery, so power cycling it is *not* an option. Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is wedged, if that's the case, and tickling it back to life? The debug unit is clocked by the core clock. So, naturally, when you stop the core clock you'll lose all debug access. There's nothing OpenOCD can do about it. As Kyle said, you can flip some bits in DBGMCU_CR to keep the debug unit clocked even in sleep modes. That will enable you to debug but of course it will also drain your battery. Thanks for the hint about DBGMCU_CR. I didn't know that, and it could prove useful. However, I don't actually want to debug in stop mode. One thing I failed to mention is that, after a system reset, the firmware puts the STM32 in run mode until it's sent a command over USB putting it into the stop/wake cycle. During this time in run mode, debugging normally works fine. The problem is that after even one attempt at debugging during stop mode, the debug unit appears permanently broken and doesn't work in *run* mode any more. Only power-cycling the STM32 fixes it. Pulling BOOT0 high during reset and sending the STM32 into its bootstrap loader doesn't help either. stop mode debugging (wfe) works fine for me if i reduce the jtag clock to something like 1kHz, but try even lower if you still have problems. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63
On 01/11/2010 00:48, Marek Vasut wrote: On Sunday 31 October 2010 18:37:33 Øyvind Harboe wrote: On Sun, Oct 31, 2010 at 6:26 PM, Peter Stugepe...@stuge.se wrote: Øyvind Harboe wrote: Is there also an upstream for Jim Tcl to make distribution packages from? Or is Jim Tcl only ever statically linked with OpenOCD? Statically linked, no change there. Ok. Has Jim Tcl ever been packaged independently? Is it our project as well? It's designed to be statically linked with applications, which means that packaging is not as important as for your typical module that is used in e.g. embedded Linux. It's not our project, but I'm a maintainer of Jim Tcl, but I hope to sit on the sideline now that Steve Bennet has stepped up. He knows a LOT more about Tcl than I do and has really cleaned up lots of stuff in Jim Tcl. Well this is weird ... won't it be better compile both jimtcl and openocd with single ./configure and make, without needing to install that stuff separatelly ? I tend to agree with this, and have a working implementation of it: http://repo.or.cz/w/openocd/ntfreak.git/shortlog/refs/heads/jimtcl The build system in jim will need updating as its a bit of a hack but can be made to work. As a side not the current make install will not install to the correct dirs, so using AC_CONFIG_SUBDIRS solves all this. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63
As a side not the current make install will not install to the correct dirs, so using AC_CONFIG_SUBDIRS solves all this. I mean under windoze install :) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Failed to receiving data from debug handler after 1000 - using jtag-tiny with colibri PXA320
On Monday 01 November 2010 10:37:41 Moshe Artzi wrote: Hi marek, The u-boot is working for me (by nand the uboot image and not by the ram) with this config: Openocd.cfg * source [find interface/jtagkey-tiny.cfg] # Change the default telnet port... telnet_port source [find board/colibri_pxa320.cfg] jtag_khz 2000 reset_config none combined * The reset_config parameter in none value did the trick for me and let me probe the nand ! I'm using: * Amontec Jtagkey-tiny * Toradex colibri pxa320 * colibri evaluation board Rev 2.1 * Open OCD 0.5.0 Thank You very much for the support. Moshe Artzi. -Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Monday, October 25, 2010 10:29 PM To: Moshe Artzi Cc: 'Takács Áron'; 'Gena Chap'; openpxa-us...@lists.sourceforge.net; openocd-development@lists.berlios.de; 'Øyvind Harboe' Subject: Re: Failed to receiving data from debug handler after 1000 - using jtag-tiny with colibri PXA320 On Monday 25 October 2010 11:38:53 Moshe Artzi wrote: Hi Marek, Sorry for the interrupt but, I'm still can't make this thing work. After nand the image I get this error: Failed to receiving data from debug handler after 1000 attempts Command handler execution failed in procedure 'resume' From my understanding, this is timing issue between the PXA320 and the Jtag but, I can't find the parameter/s that can cause this problem. Here is command line session print screen: Open On-Chip Debugger 0.5.0-dev-snapshot (2010-10-25-09:14) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' adapter_nsrst_delay: 260 jtag_ntrst_delay: 250 Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints adapter_nsrst_delay: 2000 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 200 kHz Info : device: 4 2232C Info : deviceID: 67358712 Info : SerialNumber: T1TA5HKBA Info : Description: Amontec JTAGkey A Info : clock speed 200 kHz Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009, part: 0xe642, ver: 0x7) Info : accepting 'telnet' connection from Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009, part: 0xe642, ver: 0x7) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0xf8d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled (processor reset) 1472 bytes written at address 0x5c04 downloaded 1472 bytes in 0.094000s (15.293 KiB/s) Error: Failed to receiving data from debug handler after 1000 attempts Command handler execution failed in procedure 'resume' Here is telnet session print screen: Open On-Chip Debugger reset halt ;load_image iplntim.bin 0x5c04 ;resume 0x5c04 JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009, part: 0xe642, ver: 0x7) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0xf8d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled (processor reset) 1472 bytes written at address 0x5c04 downloaded 1472 bytes in 0.094000s (15.293 KiB/s) Failed to receiving data from debug handler after 1000 attempts Command handler execution failed in procedure 'resume' I'm getting frustrated !!! ;( Hey, sorry ... I really don't know how to help you. It looks like the core halted, but it won't start at the specified address. For me, it always helped to powerdown and power-up the board. Sorry once again Any assist will be blessed, Thanks, Moshe. That's good to hear :) I'll test it myself and then ask Oyvind to merge your patch into OpenOCD. Cheers ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] setting openocd -0.4.0
Hi, I have a s5pc100 (cortex-a8) from samsung, can anyone a setup cfg file for this cpu, the development board is is from Urbetter. thanks, firas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] setting openocd -0.4.0
On Mon, Nov 1, 2010 at 5:20 PM, firas achkar fachkar.dataw...@gmail.com wrote: Hi, I have a s5pc100 (cortex-a8) from samsung, can anyone a setup cfg file for this cpu, the development board is is from Urbetter. Yes, you can. Also, you may wish to try out openocd/master branch. -- Ø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
Re: [Openocd-development] setting openocd -0.4.0
On 11/01/2010 12:22 PM, Øyvind Harboe wrote: On Mon, Nov 1, 2010 at 5:20 PM, firas achkar fachkar.dataw...@gmail.com wrote: Hi, I have a s5pc100 (cortex-a8) from samsung, can anyone provide a setup cfg file for this cpu, the development board is is from Urbetter. Yes, you can. Also, you may wish to try out openocd/master branch. what I meant what to modify in the cfg file below to make the thing work: #-- #daemon configuration telnet_port gdb_port daemon_startup attach #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag_device 4 0x1 0xf 0xe jtag_device 4 0x1 0xf 0xe jtag_nsrst_delay 200 jtag_ntrst_delay 200 #target configuration daemon_startup attach #target target arm926ejs little reset_halt 1 --- #arm7_9 etm arm7_9 etm 0 #arm7_9 etb arm7_9 etb 0 0 #target_script 0 reset csb337_init.script #working_area 0 0x2000 0x4000 nobackup #flash configuration #flash bank [driver_options ...] #flash bank cfi 0x6000 0x100 2 2 0 #flash bank cfi 0xe000 0x100 2 2 0 nand device lpc3180 0 13000 jtag_device 4 0x1 0xf 0xe jtag_device 4 0x1 0xf 0xe source [find interface/jlink.cfg] source [find target/???.cfg] --- reset_config srst_only #--- thanks, firas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
