On Wed, Aug 25, 2010 at 11:19 AM, Drasko DRASKOVIC <drasko.drasko...@gmail.com> wrote: > On Wed, Aug 25, 2010 at 8:38 AM, Laurent Gauch > <laurent.ga...@amontec.com> wrote: >>> >>> Hello David, >>> I am not so sure about this. Still smells like reset problem to me. >>> >>> It should be noted that when I let small bootloader execute from the >>> SPI flash and do the reset (and some other config), I can attach with >>> OpenOCD, i.e. chain is well scanned. I was able after attachment to >>> set-up SDRAM and launch eCos application (which would further >>> configure SoC). Now I erased the flash and tried without bootloader. I >>> do not exactly know what bootloader is doing (have not insight in the >>> code yet), but obviously nothing expect reset is needed for a proper >>> chain scanning. >>> >>> It should be also noted that Lauterbach jtag attaches without any >>> problems. I do not think that it does anything special for this step. >>> All what is needed after is few lines of SDRAM set-up and application >>> can be uploaded and run. But that comes after attachment (as for >>> OpenOCD). >>> >>> All this confirms that hardware is working properly. I am almost >>> convinced that bug is either on OpenOCD side (I tried with both ftd >>> libs) or I should configure reset in some special way... >>> >>> Would anybody have some hints after these additional explanations ? >>> >>> Best regards, >>> Drasko >>> >> >> It is not coming from your JTAGkey-2 since you can scan and detect the chain >> after configuration of your system. >> >> It is really somewhere in the OpenOCD . > > I am almost sure. As I mentioned, Lautebach works fine. So is Amontec > JTAG2 when bootloder passed before (probably doing reset correctly). > >> >> But you could try to disable the use of RTCK feature from the Amontec >> JTAGkey-2 and run at a super low frequency before doing your scan chain >> detection. > > How to do this ? In configuration file ? > > >> Also, could you please try to disconnect the JTAGkey from USB port before >> doing this. OpenOCD is still not really clean regarding the finish using the >> Amontec JTAGey as other FT2232 USB JTAG dongle before closing its handle in >> mpsse mode. > > I noted this before. When reset (USB disconnected and re-connected) > Amontec Jtag2 have only 2 green leds on. > After running one session of OpenOCD all leds stay on (mentioned two > gree + one yellow + one red). > >> Let us know the debug output in this case. > > OK, here is my procedure : > > 1) Disconnect/re-connect Amontec JtagKey2. Only two green leds are on. > 2) Commented out #jtag_rclk 1 line in config. Now config has only 3 lines : > > source [find ../tcl/interface/jtagkey2.cfg] > adapter_khz 1 > scan_chain > > That's all. I do not think that we can get slower than 1KHz > (adapter_khz 1). If yes, please tell me how. > > 3) launched openocd. It keeps getting all zeros : > > > r...@konj:~/openocd/openocd/src# ./openocd -f my_openocd.cfg > Open On-Chip Debugger 0.5.0-dev-00494-g5c98e06-dirty (2010-08-24-20:22) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.html > Info : only one transport option; autoselect 'jtag' > 1 kHz > TapName Enabled IdCode Expected IrLen IrCap IrMask > -- ------------------- -------- ---------- ---------- ----- ----- ------ > Info : max TCK change to: 30000 kHz > Info : clock speed 1 kHz > Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! > Info : inter: 0.000079, inter2: 0.000079 end: 0.653373 > Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x01273043 > ..." > Warn : AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x01273043 > ..." > Warn : AUTO auto2.tap - use "jtag newtap auto2 tap -expected-id 0x01273043 > ..." > Warn : AUTO auto3.tap - use "jtag newtap auto3 tap -expected-id 0x01273043 > ..." > Warn : AUTO auto4.tap - use "jtag newtap auto4 tap -expected-id 0x01273043 > ..." > Warn : AUTO auto5.tap - use "jtag newtap auto5 tap -expected-id 0x00000000 > ..." > Warn : AUTO auto6.tap - use "jtag newtap auto6 tap -expected-id 0x00000000 > ..." > Warn : AUTO auto7.tap - use "jtag newtap auto7 tap -expected-id 0x00000000 > ..."
I changed reference board and succeed to connect, but it was absolutely needed to prevent RTCK and to use lowest freq in the begining: #jtag_rclk 1 adapter_khz 1 jtag_khz 1 It seems that problem was really in HW, but also this should be noted - no RTCK and super-low freq. However, another problem still persist : First launch of application suceedes. SDRAM is configured and all ends well. However, after reset any next launch does not work. First, when I try to upload app it complains : > load_image /home/ddraskovic/update.elf DCC write failed, expected end address 0x00085f30 got 0x21cf07be Command handler execution failed in procedure 'load_image' Then I can disable DCC, reset init, load is reported as successful, but launch does not work. I am using ARM946E-S, but target is defined as : target create $_TARGETNAME arm966e -endian big -chain-position sqn3010_1.cpu -variant arm946e $_TARGETNAME configure -work-area-phys 0x00000000 -work-area-size 0x01000000 -work-area-backup 0 Can it be that OpenOCD does not handle well ARM946E-S after reset (because of some differences with ARM966, like coprocessor, or endianess (I am using BIG) ? Inspecting the SDRAM config registers re-initialized after reset, I's say that SDRAM is well configured and see no reason why upload breaks with DCC error, and why app can not be launched. Any hints ? Thanks and best regards, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development