Re: [Openocd-development] openocd crash when sending command over tcl_port
I had a quick peek. I can reproduce this with the dummy driver(good), but I can't see anything obviously wrong(bad). I *suspect* that the bug is not at the crash site, but that something went wrong ahead of that to cause the crash. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.html Ø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] openocd crash when sending command over tcl_port
Also... it must be said that this is probably a little tested feature, so no great surprise it doesn't work. I was wondering whether it would be the right thing to do to remove the tcl server from OpenOCD, unless someone steps up to debug, test document it. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.html Ø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] amontec jtagkey2 problems (DM365)
The's a not-very-good-workaround in place though not-very-good because it can't work when you most need it. Like, when the chip is in WFI mode (core clock gated) and thus is not responsive (which is just when you most need to reset it). (The workaround involves using the watchdog to force a reset. But if you can't talk to the core, it can't talk to the watchdog for you, hence no reset.) Another reason why this workaround is not very good is that it does not work (for me, anyway) ;-) Whenever I try to execute 'reset run', the adapter hangs - see transcript: reset run RCLK - adaptive couldn't read enough bytes from FT2232 device (0 81) couldn't read from FT2232 error: -104 Command handler execution failed in procedure 'reset' called at file command.c, line 650 called at file command.c, line 361 Thomas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] amontec jtagkey-2 problems
When the Amontec JTAGkey-2 hangs, does the internal red LED 'ON' or 'OFF' ! It is off. Thomas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] amontec jtagkey-2 problems
Hi Koeller, For some reasons, openocd hangs, also this makes the TRST to stay forced to '1'. Also, the EMU0 and EMU1 is not re-latched by the target since the TRST is still forced to '1' ! This is why you have to restart both JTAGkey-2 and your target board. Regards, Laurent http://www.amontec.com Koeller, T. wrote: When the Amontec JTAGkey-2 hangs, does the internal red LED 'ON' or 'OFF' ! It is off. Thomas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] amontec jtagkey-2 problems
Hi Thomas, Can you do a 'shutdown' command over telnet ? Regards, Laurent Koeller, T. wrote: Hi Laurent, Thank you very much for your assistance so far! For some reasons, openocd hangs, also this makes the TRST to stay forced to '1'. Also, the EMU0 and EMU1 is not re-latched by the target since the TRST is still forced to '1' ! This is why you have to restart both JTAGkey-2 and your target board. By saying 'openocd hangs', I suppose you mean that there is some kind of communication deadlock? Openocd as a whole certainly does not hang, as the telnet interface is still responsive. Can you (or anybody else) give a hint what I could do to resolve this problem? thanks again, Thomas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New driver for USBProg
Hi, I have a new OpenOCD driver for USBProg and its firmware. The new firmware is quite optimized, so it can transfer data to the SRAM with 18 KBytes/s. The old USBProg driver/firmware is much slower (1 KBytes/s). The speed comparison was done using LM3S2110 as the target board. It was tested also with some other microcontrollers (STM32, LPC2148 and AT90SAM7S256), and it works without any problems. Here is the project link : http://code.google.com/p/usbprog-jtag/ or directly to the patch against OpenOCD version 0.4.0: http://usbprog-jtag.googlecode.com/files/openocd-0.4.0-usbprog-0.1.diff Since it is a new project, the code still needs some clean up, but I think it should be ok for testing purpose. And later on, I would like also to introduce two new adapters for OpenOCD, eStick (USB adapter using AT90USB162) and USB AVR Lab: http://code.google.com/p/estick-jtag/ and http://code.google.com/p/usbvlab-jtag/ They are also already working as JTAG adapter without any problem with those microcontrollers. Any comment, test or suggestion are very welcome. Best regards, Cahya. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA270: can read/write the core registers, but can't read memory and registers of the devices on chip
Dne Pá 16. dubna 2010 09:45:09 Kaius Häggblom napsal(a): The JTAGkey-tiny dongle and board work OK, I have now successfully used the ColibriLoader software to download images to the board. ~kaius Hey, firstly, please stop top-posting (aka post below the email you are replying to or into it if you have comments to specific stuff). Kaius Häggblom wrote: The attached trace was produced by starting program: ./src/openocd -s tcl -f board/colibri_pxa320.cfg -f nterface/jtagkey.cfg -d 3 -l openocd.lo ... and issuing following commands through telnet client: reg reset halt reg cpsr 0xd3 reset halt Exactly as in original post with this issue on PXA270, writing and reading regs work OK, but anything else fails. ~kaius yvind Harboe wrote: I would strongly encourage someone who's familiar with these patches to repost them to this list so we can work on getting the changes merged. Should be in that projects and OpenOCD's interest... Ok, about this issue, I noticed weird stuff: My JTAGKey clone (FT2232 based with 74HC125 buffer and therefore 5V IO) works with: PXA320 Toradex Colibri board -- the board moreover has an internal buffer logic between the JTAG pins and the CPU PXA310 Marvell Littleton board -- the board has the JTAG pins connected directly to the CPU PXA270 Voipac board -- Directly connected too And it doesn't work with the same problems on PXA270 ZipitZ2 board. The only difference here from the Voipac board is the missing nSRST pin. Interestingly though, urJTAG works with this board with the same JTAG dongle. So it puzzles me whether it's a hardware or software issue. Cheers! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question regarding watchpoints with address mask
Does the size argument to the wp command refer to the size of a block of memor Size of what's being watched. Maybe a bank of I/O registers, etc. Yes. Ah, watching access to a bank of I/O registers is precisely what I am using my patched code for. Clearly the interpretation of the size argument is incorrect in the xscale implementation. y? I assumed it meant the size of a single access (byte, half-word, or word). Or 8 bytes for floating point etc. Note that single access is tricky to define, and that instructions like LDM/STM are not the only ones which could be deemed to perform multiple access. Yes, I see. The xscale code ignores the size value (after merely verifying a value of 1, 2, or 4), so I extrapolated from the definition used by the bp command. Defining it as you describe makes the instruction generating the access irrelevant. (I wonder if the xscale debug hardware generates the debug exception on a dma access?) The size for BP is problematic. Not all Thumb instructions are 2 bytes, not all ARM ones are 4 bytes. Hmm, I could see how these situations could cause problems with software breakpoints. Nonetheless, for software breakpoints, the size argument is really just specifying the mode the processor is running in (please correct me if I'm wrong). The xscale bp code uses it to determine whether to use the arm or thumb variant of the bkpt instruction. To interpret size of software breakpoints the same as for hardware breakpoints, you would need to fill a region of memory with bkpt instructions, after saving the original contents. And you would still need to know the processor mode. Has this been done or discussed? Seems impractical. And modes could be mixed within a region. On the other hand, trigger watch/break point on data/code access inside this region is straightforward semantics, which matches hardware well. Yes, makes sense. To summarize my understanding of the size argument to wp/bp: - wp: size of memory region, starting from the specified address - bp: software: 2=thumb mode, 4=arm mode; hardware: same as for wp The above subject to the limitations of the target's debug hardware, of course (xscale debug hardware only supports hardware breakpoints on a single address). Unless you tell me I still don't get it, I'll try to get around to patching xscale wp code to interpret size correctly. Maybe clarify the explanation in the User's Guide as well. Thanks much, Gents! Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
Hi All, I have a STM32F103ZE custom board. I have been using OpenOCD with Amontec JTAGkey2 for debugging. It works fine when I use internal SRAM (64K) as workspace. In order to run a little big program I add external SRAM (1M bytes) on FSMC (CS1) So I'd like to use this external SRAM as workspace. What should I change in target configuration ? I change workspace from 0x200 to 0x600. It doesn't work. Please let me know if there are something to change. Regards, JY Koh ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question regarding watchpoints with address mask
On Monday 19 April 2010, miked...@newsguy.com wrote: (xscale debug hardware only supports hardware breakpoints on a single address). That's not what the XScale Core Developer's Manual says: When DBR1 is programmed as a data address mask, it is used in conjunction with the address in DBR0. The bits set in DBR1 are ignored by the processor when comparing the address of a memory access with the address in DBR0. Using DBR1 as a data address mask allows a range of addresses to generate a data breakpoint. When DBR1 is selected as a data address mask, it is unaffected by the E1 field of DBCON. The mask is used only when DBR0 is enabled. When DBR1 is programmed as a second data address breakpoint, it functions independently of DBR0. In this case, the DBCON.E1 controls DBR1. A data breakpoint is triggered if the memory access matches the access type and the address of any byte within the memory access matches the address in DBRx. For example, LDR triggers a breakpoint if DBCON.E0 is 0b10 or 0b11, and the address of any of the 4 bytes accessed by the load matches the address in DBR0. Use address masking matches multiple addresses. Also on non-XScale HW. The processor does not trigger data breakpoints for the PLD instruction or any CP15, register 7,8,9,or 10 functions. Any other type of memory access can trigger a data breakpoint. For data breakpoint purposes the SWP and SWPB instructions are treated as stores - they will not cause a data breakpoint if the breakpoint is set up to break on loads only and an address match occurs. On unaligned memory accesses, breakpoint address comparison is done on a word-aligned address (aligned down to word boundary). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Getting OpenOCD working on DM355 without SRST
Hi folks, I am trying to get OpenOCD 0.4.0 (built from git) working with an Amontek JTAGKey-Tiny. I am using a home-made adapter to TI 14-pin JTAG header which has TRST but no SRST, on our board which features Texas DM355 and one other chip in the scan chain (which I don't care much about). For info we have been using the Ronetix PEEDI JTAG programmer through the same connector successfully on this board and other copies, so the design and connector are known to work. I used OpenOCD a little a couple of years ago and it's clearly come on a long way - I'm keen to play with the NAND flash support. I have copied dm355evm.cfg and customised with a couple of lines like: jtag newtap penta tap -irlen 5 -expected-id 0x04040009 # paranoia / trying to make stuff work: jtag_rclk 100 reset_config trst_only separate I can talk to the board a little, but I think I need to configure OpenOCD with a software reset or something to replace the missing SRST? On starting OpenOCD with the hardware powered up (sitting at the u-boot prompt) I get this output: Open On-Chip Debugger 0.4.0 (2010-04-13-14:08) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html RCLK - adaptive fast memory access is enabled dcc downloads are enabled RCLK - adaptive trst_only separate trst_push_pull Info : RCLK (adaptive clock speed) not supported - fallback to 100 kHz Info : JTAG tap: penta.tap tap/device found: 0x04040009 (mfg: 0x004, part: 0x4040, ver: 0x0) Info : JTAG tap: dm355.jrc tap/device found: 0x0b73b02f (mfg: 0x017, part: 0xb73b, ver: 0x0) Warn : Unexpected idcode after end of chain: 64 0x80ff Warn : Unexpected idcode after end of chain: 96 0x007f Error: double-check your JTAG setup (interface, speed, missing TAPs, ...) Info : JTAG tap: penta.tap tap/device found: 0x04040009 (mfg: 0x004, part: 0x4040, ver: 0x0) Info : JTAG tap: dm355.jrc tap/device found: 0x0b73b02f (mfg: 0x017, part: 0xb73b, ver: 0x0) Info : JTAG tap: dm355.etb enabled Info : JTAG tap: dm355.arm enabled Info : Embedded ICE version 6 Info : dm355.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.3 I can telnet in and do halt, resume, step, soft_reset_halt: soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x80d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled step target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x80d3 pc: 0x8000 MMU: disabled, D-Cache: disabled, I-Cache: disabled But reset halt complains it does not know how to reset: reset halt RCLK not supported - fallback to 1500 kHz JTAG tap: penta.tap tap/device found: 0x04040009 (mfg: 0x004, part: 0x4040, ver: 0x0) JTAG tap: dm355.jrc tap/device found: 0x0b73b02f (mfg: 0x017, part: 0xb73b, ver: 0x0) JTAG tap: dm355.etb enabled JTAG tap: dm355.arm enabled dm355.arm: how to reset? Command handler execution failed in procedure 'reset' called at file command.c, line 650 called at file command.c, line 361 target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x40d3 pc: 0x81084598 MMU: disabled, D-Cache: disabled, I-Cache: disabled Although sometimes reset halt fails - perhaps because the clock rate gets reset too high?: reset halt RCLK not supported - fallback to 1500 kHz JTAG tap: penta.tap tap/device found: 0x82020009 (mfg: 0x004, part: 0x2020, ver: 0x8) JTAG tap: penta.tap UNEXPECTED: 0x82020009 (mfg: 0x004, part: 0x2020, ver: 0x8) JTAG tap: penta.tap expected 1 of 1: 0x04040009 (mfg: 0x004, part: 0x4040, ver: 0x0) JTAG tap: dm355.jrc tap/device found: 0x0b73d817 (mfg: 0x40b, part: 0xb73d, ver: 0x0) JTAG tap: dm355.jrc UNEXPECTED: 0x0b73d817 (mfg: 0x40b, part: 0xb73d, ver: 0x0) JTAG tap: dm355.jrc expected 1 of 1: 0x0b73b02f (mfg: 0x017, part: 0xb73b, ver: 0x0) Trying to use configured scan chain anyway... Bypassing JTAG setup events due to errors Also, If I leave the board powered and halted, I get this happen after a few minutes: WARNING: unknown debug reason: 0xf target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x40d3 pc: 0x81084548 MMU: disabled, D-Cache: disabled, I-Cache: disabled Or sometimes: WARNING: unknown debug reason: 0xe invalid mode value encountered 0 cpsr contains invalid mode value - communication failure WARNING: unknown debug reason: 0xe cp15 read operation timed out cp15 read operation timed out cp15 read operation timed out cp15 read operation timed out cp15 read operation timed out cp15 write operation timed out target state: halted target halted in Thumb state due to debug-request, current mode: User cpsr: 0x8f30 pc: 0xfffa MMU: enabled, D-Cache: enabled, I-Cache: disabled While this is happening the server console sometimes prints: Jazelle debug entry --
