On Wed, Aug 25, 2010 at 5:17 PM, Drasko DRASKOVIC <[email protected]> wrote: > On Wed, Aug 25, 2010 at 11:19 AM, Drasko DRASKOVIC > <[email protected]> wrote: >> On Wed, Aug 25, 2010 at 8:38 AM, Laurent Gauch >> <[email protected]> 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 >
Also, I noted one more odd behaviour in that state when I was trying to verify what was loaded to SDRAM : > halt > poll background polling: on TAP: pera10_1.cpu (enabled) target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x60000097 pc: 0x0000000c > verify_image /home/ddraskovic/update.bin 0x00008000 timed out while waiting for target halted error executing ARM crc algorithm target not halted Command handler execution failed in procedure 'verify_image' > poll background polling: on TAP: sqn3010_1.cpu (enabled) target state: debug-running > Why does "verify_image" changes taget state form "halted" to "debug-running" ? Best regards, Drasko _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
