Re: [Openocd-development] libftdi version check in configure
openocd-development-boun...@lists.berlios.de wrote on 2009-09-21 06:38:16: While doing a regression binary search on OpenOCD revisions, I noticed only by chance that ./configure was issuing a warning about my libftdi version (I had 0.12, it wants 0.16). I then upgraded the version, eliminating the warning. What are the consequences of the version mismatch? Should this really be a warning, as opposed to making ./configure die with a failure code? Again, I noticed only by chance, as it did not cause my build command line: ./bootstrap ./configure ... make -j 2 to fail. The latest version of libftdi in the Ubuntu repositories is 0.12, so maybe this isn't an uncommon problem. Regards, Ethan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Version 0.16 allow interfaces with a FT2232H chip (USB high speed variant of FT2232C) to use a JTAG speed up to 30 MHz and also allow adaptive clocking (RTCK). Older versions of libftdi will not detect this chip and it will be treated as a FT2232C chip, so the JTAG speed will be limited to 6 MHz and adaptive clocking will not be possible. Best regards Jonas Hörberg ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] problems with FASTDATA bulk write and spansion flash
Hi Stephan, Thanks! I just saw that you are using a MIPS processor. The cfi_spansion_write_block() function supports ARM targets only. Currently this executes ARM opcodes on your machine, so you can be lucky that it returned at all :-) There is no checking the architecture yet. I believe your only choice at the moment is to not define a working area (or one that has a ~300 bytes maximum). That would ensure that the ARM code doesn't get executed because of low resources. Or maybe you want to fix it? :-) Regards, Rolf Anyone: How can I detect most efficiently that a target supports ARM code? --- Stephan Winokur m...@swinokur.com schrieb am Mo, 21.9.2009: Von: Stephan Winokur m...@swinokur.com Betreff: Re: AW: [Openocd-development] problems with FASTDATA bulk write and spansion flash An: Rolf Meeser rolfm_...@yahoo.de, openocd-development@lists.berlios.de Datum: Montag, 21. September 2009, 7:47 Hi Rolf, The device is a Spansion S29GL512P11TFI01. flash info 0 says: flash info 0 #0 : cfi at 0x4800, size 0x0400, buswidth 2, chipwidth 2 # 0: 0x (0x2 128kB) protection state unknown # 1: 0x0002 (0x2 128kB) protection state unknown # 2: 0x0004 (0x2 128kB) protection state unknown # 3: 0x0006 (0x2 128kB) protection state unknown # 4: 0x0008 (0x2 128kB) protection state unknown # 5: 0x000a (0x2 128kB) protection state unknown # 6: 0x000c (0x2 128kB) protection state unknown # 7: 0x000e (0x2 128kB) protection state unknown # 8: 0x0010 (0x2 128kB) protection state unknown [...] #510: 0x03fc (0x2 128kB) protection state unknown #511: 0x03fe (0x2 128kB) protection state unknown cfi information: mfr: 0x0001, id:0x227e qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id: 0x, alt_addr: 0x Vcc min: 2.7, Vcc max: 3.6, Vpp min: 0.0, Vpp max: 0.0 typ. word write timeout: 64, typ. buf write timeout: 64, typ. block erase timeout: 512, typ. chip erase timeout: 524288 max. word write timeout: 512, max. buf write timeout: 2048, max. block erase timeout: 4096, max. chip erase timeout: 2097152 size: 0x400, interface desc: 2, max buffer write size: 40 Spansion primary algorithm extend information: pri: 'PRI', version: 1.3 Silicon Rev.: 0x5, Address Sensitive unlock: 0x0 Erase Suspend: 0x2, Sector Protect: 0x1 VppMin: 11.5, VppMax: 12.5 At 10:40 PM 9/20/2009, Rolf Meeser wrote: Hi Stephan, What is the exact type number of the flash device? Regards, Rolf --- Stephan Winokur m...@swinokur.com schrieb am Mo, 21.9.2009: Von: Stephan Winokur m...@swinokur.com Betreff: [Openocd-development] problems with FASTDATA bulk write and spansion flash An: openocd-development@lists.berlios.de Datum: Montag, 21. September 2009, 4:45 Hi all, I'm trying to make faster flash writes happen on a mips based platform -- because this is crazy: wrote 524288 byte from file /root/flashme.bin in 45807.718750s (0.011177 kb/s). I've downloaded the svn snapshot (2734), applied the FASTDATA bulk write optimization, and made the necessary changes in my target to add a working area. (mww and mdw show me able to modify values, read them back, etc.) (the target line is: target create $_TARGETNAME mips_m4k -endian $_ENDIAN -variant ejtag_srst -chain- position $_TARGETNAME -work-area-phys 0xb010 -work-area-size 0x1000) When I try to write flash, I get this error: Debug: 260 36117 target.c:1108 target_write_buffer(): writing buffer of 2048 byte at 0xb0100060 Debug: 261 36117 mips_m4k.c:990 mips_m4k_bulk_write_memory(): address: 0xb0100060, count: 0x0200 Debug: 262 36117 target.c:962 target_alloc_working_area(): allocating new working area Info : 266 37460 mips32_pracc.c:858 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xb0100860 for write handler Debug: 267 37504 cfi.c:1562 cfi_spansion_write_block(): status: 0xb7fac190 Error: 268 37504 flash.c:100 flash_driver_write(): error writing to flash at address 0x4800 at offset 0x (-902) When I try to use load_image, I get this error: load_image /root/small.bin 0xb020 mips32_pracc_fastdata_xfer using 0xb010 for write handler User : 134 6572 mips32.c:269 mips32_arch_state(): target halted due to debug-request, pc: 0xbfc0 Debug: 136 10713 command.c:68 script_debug(): command - load_image Debug: 137 10713 command.c:77 script_debug(): load_image - argv[0]=ocd_load_image Debug: 138 10713 command.c:77 script_debug(): load_image - argv[1]=/root/small.bin Debug: 139 10713 command.c:77 script_debug(): load_image - argv[2]=0xb020 Debug: 140
[Openocd-development] board config script for Cogent CSB732 i.MX35 (arm1136)
Attached is the board config I've written for the CSB732, including
basic clocking and SDRAM initialization.
Single stepping and burst writing work correctly. I haven't tried flashing.
Regards,
Ethan
# The Cogent CSB732 board has a single i.MX35 chip
source [find target/imx35.cfg]
# Determined by trial and error
reset_config trst_and_srst combined
jtag_nsrst_delay 200
jtag_ntrst_delay 200
$_TARGETNAME configure -event gdb-attach { reset init }
$_TARGETNAME configure -event reset-init { csb732_init }
# Bare-bones initialization of core clocks and SDRAM
proc csb732_init { } {
# Disable fast writing only for init
memwrite burst disable
# All delay loops are omitted.
# We assume the interpreter latency is enough.
# Allow access to all coprocessors
arm11 mcr imx35.cpu 15 0 15 1 0 0x2001
# Disable MMU, caches, write buffer
arm11 mcr imx35.cpu 15 0 1 0 0 0x78
# Grant manager access to all domains
arm11 mcr imx35.cpu 15 0 3 0 0 0x
# Set ARM clock to 532 MHz, AHB to 133 MHz
mww 0x53F80004 0x1000
# Set core clock to 2 * 24 MHz * (11 + 1/12) = 532 MHz
mww 0x53F8001C 0xB2C01
set ESDMISC 0xB8001010
set ESDCFG0 0xB8001004
set ESDCTL0 0xB8001000
# Enable DDR
mww $ESDMISC 0x4
# Timing
mww $ESDCFG0 0x007fff3f
# CS0
mww $ESDCTL0 0x92120080
# Precharge all dummy write
mww 0x8400 0
# Enable CS) auto-refresh
mww $ESDCTL0 0xA2120080
# Refresh twice (dummy writes)
mww 0x8000 0
mww 0x8000 0
# Enable CS0 load mode register
mww $ESDCTL0 0xB2120080
# Dummy writes
mwb 0x8033 0x01
mwb 0x8100 0x01
mww $ESDCTL0 0x82226080
mww 0x8000 0
# Re-enable fast writing
memwrite burst enable
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A few thoughts on OpenOCD long term goals
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: zondag 20 september 2009 19:53 To: openocd-development@lists.berlios.de Subject: [Openocd-development] A few thoughts on OpenOCD long term goals One of my goals w/OpenOCD is that it becomes yet another thing that hardware vendors have to check off on the GCC toolchain list. Not having OpenOCD support should be like not having GDB support. This is a long way off, but it's something to aspire to. Just keep pushing. We are looking for a SoC for a new platform and we are basically saying that only devices with OpenOCD support are considered. It would be nice to have support for other targets than ARM, and we're doing well w/MIPS, but we really need a significantly bigger community or direct support from hardware vendors (the gorillas get things for free, the chimps don't...) to boast equally broad MIPS support as ARM support. Either that or ARM support has to reach a point of maturity where MIPS can start to catch up. Then again ARM is messier I don't know if MIPS is something to give much concern. IMHO MIPS is a dead platform unless the PIC32 is catching on which is unlikely since ARM devices are way ahead. Freescale's Coldfire would be much more interesting. I know Freescale is having a very hard time selling the Coldfire due to lack of Open Source tools support. The price of the devices is right, but the tooling is not. Eventually I hope that we'll be able to identify some killer features that closed source solutions just don't offer and that it will become uneconomical to implement from scratch for each JTAG debugger. I don't really know what those features might be though. Some ideas: - Threads support(e.g. eCos, FreeRTOS, etc. threads) - Profiling support(??) there is profiling support in OpenOCD now, but I haven't heard about anyone using it. - Connect up to other GPL code. We're already connected to GDB as much as we should be... What else? - Killer FPGA soft CPU workflow support(not quite sure what that means yet :-) I think the best feature is that it just works. A lot of software does not have that feature! Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd 0.3.0 + GDB + ECLIPSE not working
To Laurent Gauch: Did you received my private email? Jiri Kubias 2009/9/17 Laurent Gauch laurent.ga...@amontec.com Hi Jir(í Kubias, Good to know you resolved your problem using GDB / OpenOCD / Amontec JTAGkey-2 for your lpc2378 board. Also, thank you for giving the how you have resolved the issue. It is nice for other users. (By the way, I double checked our Amontec email box, but I did not find any email from you regarding driver troubles.) Actually, we did not have published the new driver, since we are doing Microsoft certification for our new driver. For now, Amontec Team gives the new driver on demand. But we will updated Amontec JTAGkey Dongle Drivers tomorrow (uncertified one). Please check tomorrow http://www.amontec.com . The certified one (VISTA 64 bits) should come in the next 2 weeks. Regards, Laurent Gauch http://www.amontec.com Jir(í Kubias wrote: Hi, I thought that this email didn't reach opnocd mailing list (I didnt recieve copy from mailing list). I solved my problem yesterday - the main problem was missconfigured GDB (it was configured only for i686-linux platform and not for arm-elf The second was enabled code compression - eclipse didn't survive this. Well now it works fine. I have troubles with the drivers provided on amontec web page - the windows driver is quied old (DriverVer=12/01/2005, taken from FTD2XX.inf), in linux I have the same problems so Im using the second driver usblib for ftdi chips. I reported this problem to amontec - but no response. Jirka 2009/9/17 Laurent Gauch laurent.ga...@amontec.com mailto: laurent.ga...@amontec.com Hi, Im newbie to debugging under linux at all. Im tying to make work openocd 0.3.0 + jtagkey2 + gdb + eclipse working. However Im not sucessfull. I found several problems: 1) Maybe this is not problem, but when i open opencd with jkagkey script and lpc2378 (im using lpc2364 - config is wery similar) I get this output Error: EmbeddedICE v7 handling might be broken but everything seems that is working 2) but when i use eclipse with CDT pluguin from Zylin and configure GDB with this init command; target remote localhost: set mem inaccessible-by-default off monitor halt monitor arm7_9 dcc_downloads enable monitor gdb_breakpoint_override hard monitor arm7_9 fast_memory_access enable monitor wait_halt break main continue It always fails see this log from openocd Open On-Chip Debugger 0.3.0-in-development (2009-09-16-11:44) svn:2714 $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c http://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 Warn : use 'lpc2378.cpu' as target identifier, not '0' 500 kHz Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lpc2378.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Error: EmbeddedICE v7 handling might be broken target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x2013 pc: 0x0238 Info : accepting 'gdb' connection from 0 Warn : acknowledgment received, but no packet pending Warn : memory read caused data abort (address: 0x0800, size: 0x4, count: 0x2) Warn : memory read caused data abort (address: 0x0800, size: 0x4, count: 0x1) dcc downloads are enabled force hard breakpoints fast memory access is enabled Info : dropped 'gdb' connection - error -400 the log from eclipse source .gdbinit target remote localhost: 0x0800 in ?? () set mem inaccessible-by-default off monitor halt monitor arm7_9 dcc_downloads enable dcc downloads are enabled monitor gdb_breakpoint_override hard force hard breakpoints monitor arm7_9 fast_memory_access enable fast memory access is enabled monitor wait_halt break main Breakpoint 1 at 0x64c: file /home/data/robot/eurobot/sysless-lpc21xx/app/test222/main.c, line 141. Note: automatically using hardware breakpoints for read-only addresses. continue So please help me. Im not sure if is not somethig wrong with eclipse, but is wery hard to find wiking exaple for Amontec Jtagkey2 , the lastest openocd and eclipse. OpenOCD - 0.3.0 svn build: 2741 Eclipse 3.4.1 GDB 6.8 system Gentoo Jiri Kubias The Amontec JTAGkey-2 is the new generation of Amontec JTAGkey Dongle Family. The main new features are : High-Speed / Hi-Speed USB 2.0 compliant / 30 MHz JTAG / RTCK support / auto-sense1.2V to 5.5V JTAG IOs voltage / 32 mA output drivers
Re: [Openocd-development] A few thoughts on OpenOCD long term goals
Hi, because I'm particularly newbie in Linux debugging, I have another view than you. Im trying to run jtag + openocd + gdb + something (Eclipse) to run, and there is several another problems than openocd which needs to be solved. Jtag + openocd + gdb runs perfectly (if you find your jtag and chip in / scripts) - but Im missing here some simple how-to for beginners which will be on 20 lines max. something like: Find your jtag key in /scripts/... and find your chip in /scripts/... try to run: openocd -f your_jtag.cfg -f your_chip.cfg if you see something like this ... than everything is ok. Well make openocd to work takes me cca 1/2 day work (currently release dont support jtagkey2 ...). Another problem is to make it work with some IDE. Plain GDB is for hardcore programmers. Im trying to configure Eclipse to be cool with ARM debugging - but im not eclipse guru and Im experiencing problems with breakpoint limiting (only two for HW breakpoint in LPC23xx) and viewing SFR registers Well openocd + jtag + eclipse takes me more than one day and it is not working in the way how i need it...For you it is probably easy for setup GDB scripts (will be cool to publish some with open ocd), but for beginners it is uncovered area. However tis is not directly belong to openocd project, but in future plans it may be considered. Jirka 2009/9/20 Øyvind Harboe oyvind.har...@zylin.com One of my goals w/OpenOCD is that it becomes yet another thing that hardware vendors have to check off on the GCC toolchain list. Not having OpenOCD support should be like not having GDB support. This is a long way off, but it's something to aspire to. Short term(a year or so), I'd like to see robustness for the ARM target *much* improved and the target library become increasingly support more targets and support them better. OpenOCD should be the best and cheapest alternative (in terms of engineering marketing effort) for ARM chip vendors. I'm not concerned about hardware cost to developers, because putting an ft2232 on an eval board costs $1, it doesn't get any cheaper... It would be nice to have support for other targets than ARM, and we're doing well w/MIPS, but we really need a significantly bigger community or direct support from hardware vendors (the gorillas get things for free, the chimps don't...) to boast equally broad MIPS support as ARM support. Either that or ARM support has to reach a point of maturity where MIPS can start to catch up. Then again ARM is messier than MIPS. PowerPC is hard because OpenOCD does not have the leverage to pry open the NDAs that shroud the PowerPC architecture so that gets to be a pain with open source development. In terms of getting levarage with smaller chip vendors, I believe http://www.vinchip.com is a case in point, but I have no idea if their 32 bit risc is just another ARM or whether it's something proprietary(didn't really look). Eventually I hope that we'll be able to identify some killer features that closed source solutions just don't offer and that it will become uneconomical to implement from scratch for each JTAG debugger. I don't really know what those features might be though. Some ideas: - Threads support(e.g. eCos, FreeRTOS, etc. threads) - Profiling support(??) there is profiling support in OpenOCD now, but I haven't heard about anyone using it. - Connect up to other GPL code. We're already connected to GDB as much as we should be... What else? - Killer FPGA soft CPU workflow support(not quite sure what that means yet :-) -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- === Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kub...@gmail.com mobile: 777 974167 === ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A few thoughts on OpenOCD long term goals
I've heard this concern many times, but I guess at the end of the day experienced embedded engineers have an edge Embedded development *is* quite involved... Also tools are quite rough around the edges because any particular MCU has a very narrow audience. There are *literally* 1 different MCUs out there(when you count all the parts and packagings). When you pile the # of different PCBs that exist on top of those 1 MCU parts, then you can understand that the effort into tools and support for each PCB gets *very* diluted. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A few thoughts on OpenOCD long term goals
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: maandag 21 september 2009 11:28 To: Jiří Kubias Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] A few thoughts on OpenOCD long term goals I've heard this concern many times, but I guess at the end of the day experienced embedded engineers have an edge Embedded development *is* quite involved... Also tools are quite rough around the edges because any particular MCU has a very narrow audience. True. I always tell people not to debug on embedded targets but test the software on a PC first. A PC will always have superior debugging and functional verification facilities. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
BTW I have also attached a reset-init script that not only does a soft_reset_halt and vector table remap, but also disables MAM and PLL after reset - without that two steps I experienced really crazy behaviour in a very simple and correct code while debugging. This is a little bit same what we have done recently in here. I have never figured out how these scripts could have worked out of box for anyone unless using internal RC oscillator as the only clock source Without dealing with this things went crooked from time to time. What we actually did was making another procedure function called activateInternalOsc to target script that basically does the same things described here previously; disabling PLL, switching to internal RC oscillator, etc. Most importantly: putting the target device into /known/ state. This way we didn't have to worry about what crystal or PLL settings the device is used with. This function is called from reset-init event. We also made another procedure function called writeToInternalFlash that can be evoked when we want to use OOCD just to program the FLASH memory. One of the first things this function does is calling the activateInternalOsc, again to bring the device into known state and then perform what is necessary for flash programming. - JTAG_FREQ - CRYSTAL_FREQ / 8 works for me all the times, but CRYSTAL_FREQ / 6 - not (in the .tcl file I divide by 8 now) Agreed. Divided by 8 seems to be a more stable option in here as well. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Why are you doing a soft_reset_halt? Why not? If this command is forbidden / wrong / whatever - remove it. If it's not, why do you care if I use it? Without that command it does not work. Or maybe I just don't understand the meaning of reset init? For me that is do a reset, init everything that should be initialized. If that's not the case, then the name should be changed, as it's misleading. I asked because I recently removed soft_reset_halt from lpc2478.cfg because it made things fail. I have no idea *why* it fails, so I hoped that you could shed light on that problem. We have fiddled so much with the config files in here that I lost track of affects long time ago. But in our current script we use soft_rest_halt as well (while using LPC23xx series, I'm not sure if we have tried it out with LPC2478 - we do have board for this as well). Bottom line is that it works for us - I don't know about other people or even less why it works without. Now following is just flow of mind thus may include major errors but hopefully will arise some conversation. What is the purpose of reset-init event? In my opinion it is where we want to get things back to the beginning. Performing system reset may reset other hardware on target board as well and may cause some major trouble while debugging. I don't like doing this anyway as it causes the EmbeddedICE logic to reset as well and OOCD to lose control for a moment. Soft reset makes a fake reset by altering the program counter, leaving the hardware to probably steady yet unknown state. This is why we need additional steps to configure some peripherals or clock source to fixed, known state as discussed before. Then we let the embedded software to handle rest of the initializations - just like if it was coming out from any ordinary reset. From what I have experienced, soft_reset_halt is a safe way of reseting the system. Then again the problems we have had, may all be just our own fooling with the OOCD and that utterance may not be true. OOCD isn't one of the easiest choices for debugging on the market. Regards, Petri ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
0.3 anyone? There's lots of good progress since 0.2. Does anyone have a bunch of stuff that will be completed in the near future? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
Øyvind Harboe pisze: Does anyone have a bunch of stuff that will be completed in the near future? How about that new LPC2xxx cfg files layout? With a bit of investigation the reset init should be working, or that can be left for future, as now this script is not fully functional either... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
On Monday 21 September 2009, Petri Pirttinen wrote: What is the purpose of reset-init event? In my opinion it is where we want to get things back to the beginning. A reset halt is intended to reset and cause a halt before execution of the first post-reset instruction. That's back to the beginning, if you will. A reset init is the same as a reset halt *EXCEPT* that it also runs a Tcl reset-init event handler. Re what the reset-init handler should do ... lowlevel setup for the board. On most ARM9 class chips it would be doing what the boot loader does: set up clocks and PLL, switch core to PLL-based clocking, set up external SDRAM or DDR2, probe flash chips, and more. Performing system reset may reset other hardware on target board as well and may cause some major trouble while debugging. I don't like doing this anyway as it causes the EmbeddedICE logic to reset as well and OOCD to lose control for a moment. That seems like a different issue. I agree that it would be good to avoid issuing SRST ... that's a general limitation of the current OOCD reset framework, that it uses SRST (and for that matter TRST!) way too readily, *AND* doesn't have good alternatives (yet). Resetting the EmbeddedICE logic ... I don't believe that's a general characteristic of SRST on ARMs. Though it does sound like it's true on LPC2xxx chips. (Example, ARM920 and ARM926 boards I have here could not implement reset halt if SRST covered the EmbeddedICE. The halt mechanism uses the vector catch hardware to trap right after reset.) Like my current pet peeve: how to get OpenOCD to reboot a system which doesn't have SRST wired. After I finish chasing down the current set of problems, I'll do something about that. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
Hi,
I had problems with the reset init on LPC2478, too. I didn't analyze it
deeply, but I noticed this problem:
OpenOCD reported that it couldn't halt the target. With debug on, I got the
impression that the EmbeddedICE had been programmed for a break before the
final SRST/TRST happened. There was an attempt to reprogram it afterwards, but
that didn't seem to be complete.
I've added a call to jtag_add_tlr(), and that solved it for me.
All relevant EmbeddedICE registers are now reprogrammed.
It looks like there's some internal state which didn't notice that the target
hardware got a reset. Seems reasonable to me to have the TAP reset call here,
but I'm not an expert...
Regards,
Rolf
Index: src/target/arm7_9_common.c
===
--- src/target/arm7_9_common.c (revision 2731)
+++ src/target/arm7_9_common.c (working copy)
@@ -1105,6 +1105,9 @@
if (target-reset_halt (jtag_reset_config RESET_SRST_PULLS_TRST)
!= 0)
{
LOG_WARNING(srst pulls trst - can not reset into halted mode.
Issuing halt after reset.);
+
+ jtag_add_tlr();
+
/* set up embedded ice registers again */
if ((retval = target_examine_one(target)) != ERROR_OK)
return retval;
--- Freddie Chopin freddie_cho...@op.pl schrieb am Mo, 21.9.2009:
Von: Freddie Chopin freddie_cho...@op.pl
Betreff: Re: [Openocd-development] 0.3 anyone?
An: Øyvind Harboe oyvind.har...@zylin.com
CC: openocd-development@lists.berlios.de
Datum: Montag, 21. September 2009, 19:04
Øyvind Harboe pisze:
Does anyone have a bunch of stuff that will be
completed in the near future?
How about that new LPC2xxx cfg files layout?
With a bit of investigation the reset init should be
working, or that
can be left for future, as now this script is not fully
functional either...
4\/3!!
___
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
Re: [Openocd-development] new lpc2xxx cfg files layout
On Saturday 19 September 2009, Freddie Chopin wrote: I don't know how should the GDB initialization commands look like: monitor reset init load (let's call that v1) That should work. If it doesn't, there's a bug lurking somewhere. or maybe: monitor reset halt monitor reset init load (let's call that v2) reset init is reset halt plus execution of the reset-init event handler. So if v2 behavior *differs* in any way from v1 behaviour, this is a bug ... doing reset halt twice should be exactly equivalent to doing it once. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
On Saturday 19 September 2009, Freddie Chopin wrote: 1. When there is soft_reset_halt in the script: v1 fails - target not halted v1 (without load) - works v2 fails - target not halted v2 (without load) - works But: When I want to load I have to do: monitor reset halt load monitor reset init or: monitor reset init monitor reset halt load And this way it works Sounds like the soft_reset_halt doesn't belong, then, especially given (2) below: 2. When there is no soft_reset_halt in the script: v1 works v1 (without load) fails / works wrong v2 works v2 (without load) works wrong ... except for those without load cases. 3. When there is armv4_5 core_state arm instead of soft_reset_halt: v1 works v1 (without load) works wrong v2 works v2 (without load) works wrong For 2. and 3. cases that fail, I need to manually add soft_reset_halt in the gdb init command for things to work. Generally most of the time monitor reset halt + monitor soft_reset_halt alone works fine, but sometimes enabled MAM and PLL make things go crazy... Normally a reset halt should have caused MAM and PLL to enter their just-after-hard-reset hardware default states ... Are you saying those hardware default states cause problems? If so, that seems buggy. I'm not sure where the issue would lie, but it's hard to imagine the chips could boot properly if the hardware defaults didn't work ... This would be pretty cool to just use lpc2xxx like stm32: monitor reset halt (+ load) and that's all. I think the fact that it doesn't work reflects a bug. But I don't know those LPC chips, or thus where the bug would be. That's doesn't have to be -halt but having reset init do all the job would be great, as now that's a lottery and shooting in the dark. On a microcontroller -- ARM7TDMI plus flash -- I would expect that if the 'reset-init' script just probed the flash chips that should suffice. Do one reset init and from then on the reset halt *SHOULD* be enough. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
David Brownell pisze: Normally a reset halt should have caused MAM and PLL to enter their just-after-hard-reset hardware default states ... Are you saying those hardware default states cause problems? If so, that seems buggy. I'm not sure where the issue would lie, but it's hard to imagine the chips could boot properly if the hardware defaults didn't work ... Well, all LPC2xxx chips are srst_pulls_trst - that's the first thing. Moreover - due to internal bootloader operation there is some delay between de-asserting reset and activating the JTAG interface (this is some protection mechanism). That's why on LPC2xxx reset halt does: 1. reset 2. wait a while 3. halt 4. do a soft_reset_halt during 2. there is enough time for the core to execute A LOT of instructions, like enabling MAM and PLL, which DO cause trouble whan you expect them to be disabled. I haven't investigated that much, but I thing there is some hidden bug in soft_reset_halt, that makes programming (via gdb's load) fail with target not halted (and yet - just before the load a poll command shows, that the core is halted /; ) I think the fact that it doesn't work reflects a bug. But I don't know those LPC chips, or thus where the bug would be. That's a silicon limitation of LPC chips... For example in CrossWorks this is overcome by injection a startup with a forever loop that is later skipped by the debugger - this way at the start of the debugging session the chip is in good state. Unfortunately something like this cannot be implemented without build-tools integration /; Or maybe I'm wrong? One way could be to implement some king of hardware reset (maybe via Watchdog?), the other - to halt the execution in some infinite loop... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Mon, Sep 21, 2009 at 7:04 PM, Freddie Chopin freddie_cho...@op.pl wrote: Øyvind Harboe pisze: Does anyone have a bunch of stuff that will be completed in the near future? How about that new LPC2xxx cfg files layout? With a bit of investigation the reset init should be working, or that can be left for future, as now this script is not fully functional either... When it's ready it should be committed, but I think this is one thing that either is ready by the time we cut 0.3 or not, we don't push out 0.3 for these changes. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
Øyvind Harboe pisze: When it's ready it should be committed, but I think this is one thing that either is ready by the time we cut 0.3 or not, we don't push out 0.3 for these changes. For me, the main cfg files layout is ready, I can make a patch even today. I'm just waiting for the opinions and a go sign. The reset-init script IMHO is a separate issue, which should be investigated further. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in GDB handling of halted/running state
I'm wondering if it would be a good idea to modify the handling of GDB halted/running state as follows: - do nothing upon attaching GDB to OpenOCD. This gives the GDB init script more freedom w.r.t. what should happen when connecting to the target. - if the target is running and GDB is halted, then OpenOCD returns white lies in the register and memory queries. This allows users to issue a monitor halt or stepi/continue command after attaching to either halt the target or sync up with it. - When connecting to a halted target, the next stepi/continue returns immediately, thus allowing the register state to sync up to the current state of the target without modifying the state of the target - if, while GDB is halted, the target state changes behind GDBs back, then the next stepi/continue returns immediately to sync up GDB to the current state -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Hi, Im using LPC2364 with modified sample target/lpc2378.cfg with interface/jtagkey2.cfg and with modification reset_config none (I dont have connected reset to JTAG). My GDB flash init is: target remote localhost: monitor soft_reset_halt monitor gdb_breakpoint_override hard d b main c And I dont find out any strange behaviour. But there is several recommendations which you must take in care. 1) In setup PLL you must check if PLL is connected or if is locked - if yes you must disconnect it!!! If you dint check it, it should produce some errors during setup JTAG interface. Im dont know why but this part is often missing in published code... 2) if you are using JTAG is highly recommended to add long busy wait before startup routine is called. (Im using cca 0.5 sec dummy wait) The JTAG start routine runs processor for a while - it runs application code. Jirka 2009/9/21 Freddie Chopin freddie_cho...@op.pl David Brownell pisze: Normally a reset halt should have caused MAM and PLL to enter their just-after-hard-reset hardware default states ... Are you saying those hardware default states cause problems? If so, that seems buggy. I'm not sure where the issue would lie, but it's hard to imagine the chips could boot properly if the hardware defaults didn't work ... Well, all LPC2xxx chips are srst_pulls_trst - that's the first thing. Moreover - due to internal bootloader operation there is some delay between de-asserting reset and activating the JTAG interface (this is some protection mechanism). That's why on LPC2xxx reset halt does: 1. reset 2. wait a while 3. halt 4. do a soft_reset_halt during 2. there is enough time for the core to execute A LOT of instructions, like enabling MAM and PLL, which DO cause trouble whan you expect them to be disabled. I haven't investigated that much, but I thing there is some hidden bug in soft_reset_halt, that makes programming (via gdb's load) fail with target not halted (and yet - just before the load a poll command shows, that the core is halted /; ) I think the fact that it doesn't work reflects a bug. But I don't know those LPC chips, or thus where the bug would be. That's a silicon limitation of LPC chips... For example in CrossWorks this is overcome by injection a startup with a forever loop that is later skipped by the debugger - this way at the start of the debugging session the chip is in good state. Unfortunately something like this cannot be implemented without build-tools integration /; Or maybe I'm wrong? One way could be to implement some king of hardware reset (maybe via Watchdog?), the other - to halt the execution in some infinite loop... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- === Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kub...@gmail.com mobile: 777 974167 === ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase
David Brownell wrote:
On Sunday 20 September 2009, Johnny Halfmoon wrote:
+ if ((retval = flash_check_sector_parameters(cmd_ctx, first,
last, p-num_sectors)) !
I had in mind more like
uint32_t value;
Okay. Like this then:
= = = = = = = = = = = =
doc/openocd.texi |6 ++-
src/flash/flash.c | 97 +++---
2 files changed, 67 insertions(+), 36 deletions(-)
Index: src/flash/flash.c
===
--- src/flash/flash.c (revision 2736)
+++ src/flash/flash.c (working copy)
@@ -559,40 +559,62 @@
return ERROR_OK;
}
+int flash_check_sector_parameters(struct command_context_s *cmd_ctx, uint32_t
first, uint32_t last, uint num_sectors)
+{
+ if ( first = last ) {
+ command_print(cmd_ctx, ERROR: last sector must be first
sector);
+ return ERROR_FAIL;
+ }
+
+ if ( last (num_sectors - 1)) {
+ command_print(cmd_ctx, ERROR: last sector must be = %d,
num_sectors - 1);
+ return ERROR_FAIL;
+ }
+
+ return ERROR_OK;
+}
+
static int handle_flash_erase_command(struct command_context_s *cmd_ctx, char
*cmd, char **args, int argc)
{
if (argc 2)
{
- int first = strtoul(args[1], NULL, 0);
- int last = strtoul(args[2], NULL, 0);
+ uint32_t bank_nr;
+ uint32_t first;
+ uint32_t last;
int retval;
- flash_bank_t *p = get_flash_bank_by_num(strtoul(args[0], NULL,
0));
+
+ if ((retval = parse_u32(args[0], bank_nr)) != ERROR_OK)
+ return retval;
+
+ flash_bank_t *p = get_flash_bank_by_num(bank_nr);
+ if (!p)
+ return ERROR_OK;
+
+ if ((retval = parse_u32(args[1], first)) != ERROR_OK)
+ return retval;
+ if (strcmp(args[2], last) == 0)
+ last = p-num_sectors - 1;
+ else
+ if ((retval = parse_u32(args[2], last)) != ERROR_OK)
+ return retval;
+
+ if ((retval = flash_check_sector_parameters(cmd_ctx, first,
last, p-num_sectors)) != ERROR_OK)
+ return retval;
+
duration_t duration;
char *duration_text;
-
duration_start_measure(duration);
- if (!p)
- {
- return ERROR_COMMAND_SYNTAX_ERROR;
- }
-
- if ((retval = flash_driver_erase(p, first, last)) == ERROR_OK)
- {
+ if ((retval = flash_driver_erase(p, first, last)) == ERROR_OK) {
if ((retval = duration_stop_measure(duration,
duration_text)) != ERROR_OK)
- {
return retval;
- }
-
- command_print(cmd_ctx, erased sectors %i through %i on
flash bank %li in %s,
- first, last, strtoul(args[0], 0, 0),
duration_text);
+ command_print(cmd_ctx, erased sectors %i through %i on
flash bank %i in %s,
+ first, last, bank_nr, duration_text);
free(duration_text);
}
}
else
- {
return ERROR_COMMAND_SYNTAX_ERROR;
- }
return ERROR_OK;
}
@@ -601,40 +623,47 @@
{
if (argc 3)
{
- int first = strtoul(args[1], NULL, 0);
- int last = strtoul(args[2], NULL, 0);
+ uint32_t bank_nr;
+ uint32_t first;
+ uint32_t last;
+ int retval;
int set;
- int retval;
- flash_bank_t *p = get_flash_bank_by_num(strtoul(args[0], NULL,
0));
+
+ if ((retval = parse_u32(args[0], bank_nr)) != ERROR_OK)
+ return retval;
+
+ flash_bank_t *p = get_flash_bank_by_num(bank_nr);
if (!p)
- {
- command_print(cmd_ctx, flash bank '#%s' is out of
bounds, args[0]);
return ERROR_OK;
- }
+ if ((retval = parse_u32(args[1], first)) != ERROR_OK)
+ return retval;
+ if (strcmp(args[2], last) == 0)
+ last = p-num_sectors - 1;
+ else
+ if ((retval = parse_u32(args[2], last)) != ERROR_OK)
+ return retval;
+
if (strcmp(args[3], on) == 0)
set = 1;
else if (strcmp(args[3], off) == 0)
set = 0;
else
- {
return ERROR_COMMAND_SYNTAX_ERROR;
- }
+
Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase
Hi Johnny,
it should be
+if ( first last ) {
not
+if ( first = last ) {
With first=last you can erase a single sector.
Regards,
Rolf
--- Johnny Halfmoon jhalfm...@milksnot.com schrieb am Mo, 21.9.2009:
Von: Johnny Halfmoon jhalfm...@milksnot.com
Betreff: Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last
sector for protection and erase
An: David Brownell davi...@pacbell.net
CC: openocd-development@lists.berlios.de
Datum: Montag, 21. September 2009, 21:33
David Brownell wrote:
On Sunday 20 September 2009, Johnny Halfmoon wrote:
+
if ((retval =
flash_check_sector_parameters(cmd_ctx, first, last,
p-num_sectors)) !
I had in mind more like
uint32_t value;
Okay. Like this then:
= = = = = = = = = = = =
doc/openocd.texi | 6 ++-
src/flash/flash.c | 97
+++---
2 files changed, 67 insertions(+), 36 deletions(-)
Index: src/flash/flash.c
===
--- src/flash/flash.c (revision 2736)
+++ src/flash/flash.c (working copy)
@@ -559,40 +559,62 @@
return ERROR_OK;
}
+int flash_check_sector_parameters(struct command_context_s
*cmd_ctx, uint32_t first, uint32_t last, uint num_sectors)
+{
+ if ( first = last ) {
+
command_print(cmd_ctx, ERROR: last sector must be
first sector);
+ return ERROR_FAIL;
+ }
+
+ if ( last (num_sectors - 1)) {
+
command_print(cmd_ctx, ERROR: last sector must be =
%d, num_sectors - 1);
+ return ERROR_FAIL;
+ }
+
+ return ERROR_OK;
+}
+
static int handle_flash_erase_command(struct
command_context_s *cmd_ctx, char *cmd, char **args, int
argc)
{
if (argc 2)
{
- int first =
strtoul(args[1], NULL, 0);
- int last =
strtoul(args[2], NULL, 0);
+ uint32_t bank_nr;
+ uint32_t first;
+ uint32_t last;
int retval;
- flash_bank_t *p =
get_flash_bank_by_num(strtoul(args[0], NULL, 0));
+
+ if ((retval =
parse_u32(args[0], bank_nr)) != ERROR_OK)
+
return retval;
+
+ flash_bank_t *p =
get_flash_bank_by_num(bank_nr);
+ if (!p)
+
return ERROR_OK;
+
+ if ((retval =
parse_u32(args[1], first)) != ERROR_OK)
+
return retval;
+ if (strcmp(args[2],
last) == 0)
+
last = p-num_sectors - 1;
+ else
+
if ((retval = parse_u32(args[2], last)) != ERROR_OK)
+
return retval;
+
+ if ((retval =
flash_check_sector_parameters(cmd_ctx, first, last,
p-num_sectors)) != ERROR_OK)
+
return retval;
+
duration_t
duration;
char
*duration_text;
-
duration_start_measure(duration);
- if (!p)
- {
-
return ERROR_COMMAND_SYNTAX_ERROR;
- }
-
- if ((retval =
flash_driver_erase(p, first, last)) == ERROR_OK)
- {
+ if ((retval =
flash_driver_erase(p, first, last)) == ERROR_OK) {
if ((retval = duration_stop_measure(duration,
duration_text)) != ERROR_OK)
-
{
return retval;
-
}
-
-
command_print(cmd_ctx, erased sectors %i through %i on
flash bank %li in %s,
-
first, last, strtoul(args[0], 0, 0),
duration_text);
+
command_print(cmd_ctx, erased sectors %i through %i on
flash bank %i in %s,
+
first, last, bank_nr, duration_text);
free(duration_text);
}
}
else
- {
return
ERROR_COMMAND_SYNTAX_ERROR;
- }
return ERROR_OK;
}
@@ -601,40 +623,47 @@
{
if (argc 3)
{
- int first =
strtoul(args[1], NULL, 0);
- int last =
strtoul(args[2], NULL, 0);
+ uint32_t bank_nr;
+ uint32_t first;
+ uint32_t last;
+ int retval;
int set;
- int retval;
- flash_bank_t *p =
get_flash_bank_by_num(strtoul(args[0], NULL, 0));
+
+ if ((retval =
parse_u32(args[0], bank_nr)) != ERROR_OK)
+
return retval;
+
+ flash_bank_t *p =
get_flash_bank_by_num(bank_nr);
if (!p)
- {
-
command_print(cmd_ctx, flash bank '#%s' is out of bounds,
args[0]);
return ERROR_OK;
- }
+ if ((retval =
parse_u32(args[1], first)) != ERROR_OK)
+
return retval;
+ if (strcmp(args[2],
last) == 0)
+
last = p-num_sectors - 1;
+ else
+
if ((retval = parse_u32(args[2], last)) != ERROR_OK)
+
return retval;
+
if (strcmp(args[3],
on) == 0)
set = 1;
else if
(strcmp(args[3], off) == 0)
set = 0;
else
- {
return ERROR_COMMAND_SYNTAX_ERROR;
- }
+ if ((retval =
Re: [Openocd-development] new lpc2xxx cfg files layout
Freddie Chopin wrote:
Here is the patch that adds the lpc2xxx_internals.tcl file and
modifies all lpc2xxx (ARM7) files to use that.
1) Looks good, I agree the reset issue can be resolved later.
2) Only thing I can think of is this.. type of a change
But that is a minor thing, I hate hidden default values.
They are MAGIC - that always mess me up, been burned one too many
many times.
+# check for RESET_CONFIG - if not defined set the default: trst_and_srst
+if { [info exists RESET_CONFIG ] } {
+ set _RESET_CONFIG $RESET_CONFIG
+} else {
+ set _RESET_CONFIG trst_and_srst
+ puts WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG
+}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Duane Ellis pisze:
2) Only thing I can think of is this.. type of a change
But that is a minor thing, I hate hidden default values.
They are MAGIC - that always mess me up, been burned one too many
many times.
+# check for RESET_CONFIG - if not defined set the default: trst_and_srst
+if { [info exists RESET_CONFIG ] } {
+set _RESET_CONFIG $RESET_CONFIG
+} else {
+set _RESET_CONFIG trst_and_srst
+ puts WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG
+}
I also thought about that, but... in here such line does not print any
output in the console... It doesn't get printed even with -d 3, so I
have no idea what's wrong.
Any clues? I'd gladly add some warning messages to this file when the
default values are selected.
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
Have you tried firing up openocd in the debugger? CFLAGS=-O0 -g configure ... insight --args openocd args Hook up scope and set a breakpoint in main(), start debugging... -- Øyvind Harboe ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Tue, Sep 22, 2009 at 12:03 AM, David Brownell davi...@pacbell.net wrote: On Monday 21 September 2009, Rolf Meeser wrote: I've added a call to jtag_add_tlr(), and that solved it for me. All relevant EmbeddedICE registers are now reprogrammed. Did you try for example just adding a bunch of TCK cycles, via runtest? Or maybe just reading a register? (There's code elsewhere which uses register reads to work around things not getting set as expected.) We have too many add_tlr() calls already, and on systems with an ICEpick they will take the ARMs out of the scan chain. It's bad enough that happens four (!) times during a reset -- I want to get rid of most of them -- but let's not add them elsewhere except possibly as variant-specific behaviors. Could he be repairing a bug in the driver where the driver does not track the JTAG state correctly after a srst that pulls trst? -- Øyvind Harboe ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
