Re: [Openocd-development] SRST TRST have to be buffered?
I'm trying to embed a FT2232D based programmer into my board with a STM32 (Cortex-M3 MCU). I want the programmer to be compatible with jtagkey, so I looked at schematics of compaible designs. I noticed that while the JTAG signals (TCK, TDI, TDO, TMS) are only buffered when translation is necessary, the SRST and TRST signals are always tri-state buffered, with OE going into the FTDI chip. Is there a reason for that? Can I omit the buffers? Since you are embedding the JTAG interface with the target, you can tell if buffering is needed. We just went through a similar exercise and you can pretty much hook everything up directly and use the FTDI MiniModule layout (see commit from Rodrigo Rosa) if you target circuit is right. Also, I heard it's possible to omit the TRST signal and only keep the SRST signal, because system reset will also reset the TAP controller. Is that true? Are there problems with that? TRST is optional since you can reset the JTAG TAP state machine with clocking TCK which TMS=1. SRST might be needed for other reasons. For example some chips need it as part of some kind of flash / code protection enable/disable. Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
The best is to standardize at a lower level ... and to forget the idea to have the possibility to bitbang from the TCL of the openocd. That's as for the SWD, we have to standardize some function call in the ft2232, and avoiding bitbang access from higher-level. That's not simple to dev, but safe for end-user. It is necessary to expose the feature though TCL. Otherwise it is not possible to use it as the telnet TCL interface is the primary (only?) way for you to control OpenOCD. Furthermore, this is the interface to use if you want to use OpenOCD from another program. I do not understand the opposition to making OpenOCD more flexible by reducing the need to modify the source and re-building to achieve some functionality. You can already do plenty of unsafe things with OpenOCD like erasing the entire flash of your target. Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
My objective is not to block feature.Never,never,never ... But we have to avoid any trouble in generic ft2232 driver regarding specific layout. That's all. Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? You have two solutions: You need to write a specifc driver (), or you need to filter the TCL bitbang action in the ft2232 generic driver. The filter must be specifc to the open layout ... The same is for SRST TRST control. The ft2232.c driver has specific functions for SRST TRST regarding layout used ... we have to do this for ANY other specific layout signal in the ft2232.c or write a specific driver. I think there is an misunderstanding here. My reading of Tomek's emails indicates there is a layout specific mechanism to filter which pins can be bitbanged. The interface config file will define which pins can be bitbanged and how. Is this correct? Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
(Resending since I forgot to cc the list) There is at least one useful end-user use case for bitbanging. There are many IO lines unused on the FTDI port that can be used for GPIO. Some dongles expose these and of course a custom FTDI interface that you integrate with your prototype can expose these. If the generic FTDI code does not expose this functionality, the alternative is to modify the layout specific parts to support this. The downside is that if you make a custom FTDI interface on your prototype you may need to write your own layout driver. Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Firmware download to JTAG adapter from OpenOCD driver
Another way would be to implement a minimalistic Intel HEX parser in the ULINK driver or in a separate C module. If you are looking for an Intel HEX parser, look in targets/image.c. There it parses Intel Hex, ELF, and Srec files. Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Firmware download to JTAG adapter from OpenOCD driver
Thanks - I tried that, it recognizes the correct amount of sections and their sizes in the ihex file but not the base address - I am getting random values when reading the base_address member in the struct imagesection. Am I supposed to read the section address from that variable or is there something I'm overlooking? I have not used this code myself so I'm not sure how you are supposed to use it. However, I think it is used by the load_image command so if it's broken than load image is broken. Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SVF echo does not show SDR commands
I've been programming Lattice XP2 FPGAs with SVF using a git checkout from the beginning of February. (So, to answer Oyvind svf at least partially works.) However, I've noticed that the echo to the screen does not echo the first line of SDR commands. The SVF has SDR commands of the form: SDR638TDI (3FFFFFFEEEFFFFFF FFFFFFFFEE6EFFFF); The output in the telnet session and the OpenOCD console only shows the second line. If SDR command is only one line, nothing is shown. Is this intentional? Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SVF echo does not show SDR commands
Ah, this'll probably be my fault, and it's not intentional must be something I missed when I modified the verbose stuff late last year. I've only been using the svf command to program my actel fpga with an auto-generated svf file, and haven't noticed this issue, either because I don't get multiline commands in the generated file, or because they flick past the screen so fast I don't notice them! Yes, I did not notice at first either. I only noticed when I looked more closely. Do you now whether the command are being run correctly? I assume because you haven't said otherwise then they must be, just not getting printed. As far as I can tell, the commands work since programming the FPGA works. Occasionally, it fails when it gets to the verification step, but I have not been able to determine why. Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] dsp568013 - switching/disabling taps
you can try configure with --enable-verbose-jtag-io. All the jtag input/output is done in interface.c. I'm assuming this will help us see what is shifted in during the irscan commands. Any ideas on how to configure OpenOCD to handle the tap switching? Our current method does not handle the case when tapdisable is called. The disable functions are empty because they are just used to signal OpenOCD that one tap is disabled with the other is enabled. Phil Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] JTAG_STABLECLOCKS for jlink
After some experimenting with building the right cable and generating an appropriate SVF file, I was able to program a Lattice XP2 using OpenOCD and a Signalyzer-H2. Since I also have a jlink, I figured why not give that a shot. It seems that the jlink does not have the JTAG_STABLECLOCKS jtag command implemented which is required for this SVF file. Poking around jlink.c, seems to indicate that JTAG_STABLECLOCKS could be implemented using jlink_tap_append_step() if you knew what TDI should be during the clocking. Any clues on how to figure out what TDI is supposed to be? Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] current windows gdb gui options
I have had some success with Code::Blocks on Windows. On Linux it works fine. On Windows there are a few annoyances. The main one is how to halt remote targets. With OpenOCD I do it through the telnet interface. See the discussion at http://forums.codeblocks.org/index.php/topic,12412.0.html. Phil - Original Message From: Duane Ellis open...@duaneellis.com To: OpenOCD Development openocd-development@lists.berlios.de Sent: Sat, September 4, 2010 4:04:29 AM Subject: [Openocd-development] current windows gdb gui options For years, I have used gdb-insight - (the Tcl/Tk version of GDB) http://sourceware.org/insight/ However, it has grown long in the tooth, and cygwin has moved on. At this point, the changes in Cygwin have broken the private copy of Tcl/Tk (from 2004), Some notes: Insight has always had a private copy of Tcl/Tk Tcl/Tk dropped cygwin support years ago GDB/Insight no longer builds, and looks painful to fix. Q: What are the openocd + gdb + windows users using as their GUI front end? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Single stepping problem on LPC3220
I have found some situations where single step with next in GDB with OpenOCD on a LPC3220 (uses lpc3250.cfg with modification of core ID and memory size), does not work. Whenever I reach a certain line while single stepping, OpenOCD prints out Error: Unable to set 32 bit software breakpoint at address 81a8 - check that memory is read/writable twice and Warn : breakpoint not set. After this happens, I cannot continue past this line, next does not return unless I press control-c and it's still on the same line. If I try with continue it immediately returns but is still on the same line. Disassembly around that address is: 0x819c +4:bl0x8228 system_init 0x81a0 +8:ldrr0, [pc, #16]; 0x81b8 main+32 0x81a4 +12:bl0x80002da4 puts = 0x81a8 +16:bl0x8000192c get_debug_uart 0x81ac +20:bl0x80001848 uart_close 0x81b0 +24:movr0, #0 I have the same behavior with both 0.4.0 and a git clone from yesterday. I am using a j-link on Linux but have seen the same problem with a signalyzer (ft2232 based) on another Linux machine as well. The same program works fine if I use continue before I get to the problematic line. If a log at log level 3 is needed, how much of log do I need to send? It prints out a lot of information. Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
