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.
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. --Michal On Sun, 2009-09-13 at 09:34 +0200, Øyvind Harboe wrote: > > So r1817 passed but r1822 does not. r1817-r1821 do not compile. > > > > There are a lot of changes to jtag.c file here between r1817 - r1822. > > Anybody? > > I've diffed 1817 and 1822 and I find nothing that could explain > arm11 burst writes failing. It's quite puzzling. > > The only difference I could find by reading the code is > timing changes, i.e. it happens to break between 1817 and > 1822 on your machine + interface, but it would break > somewhere else on another setup. If this is the case, then > the code was *always* broken(i.e. not robust), it just > happened to work. > > The other hint that you have found is that removing TAP_IDLE's > will make the code work, i.e. the faster the code is, the better > chance it is of it running. If *timing* is the only difference > when removing/adding TAP_IDLE's, then this is another hint > at a race condition. > > These next steps come to mind: > > 1. Verify assumptions. Are you *sure* 1817 work and 1822 fails? > > 2. Try to break 1822. Try adding usleep() delays around the > code, e.g. to jtag_execute_queue(). > > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
