On Sun, Sep 13, 2009 at 11:26 PM, michal smulski <michal.smul...@ooma.com> wrote: > It does seem that this is a timing issue. However adding various > usleep() around jtag.c and arm11_dbtap.c file does not produce errors on > r1817. Also increasing TAP_IDLE's does not break the code.
Did you also double check that 1822 breaks? > It might be more productive to capture some of the data going to ft2232 > interface. Is there a simple way to add LOG_INFO()'s to show what is > being send out onto USB cable (in terms of commands or actual bits)? I > can add some timing info as well and compare r1817 & r1822 output > versions. > > Since all the data is written to memory and it is always correct, then > all arm11 commands (32-bit memory writes) are executed correctly. So, > the only issue is really with address incrementing. Which part of the > code causes the memory pointer to increment? Perhaps I can look at that > code. The burst code is executing two instructions to increment the pointer. Perhaps the second instruction is getting executed twice? -- Ø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
