Magnus Lundin wrote: > Here is a patch that helps against the well known OVERRUN errors for > Cortex-M3 ( the problem is even worse for Cortex-A8 ) > > Basically the patch adds a fixed number ( default 8 ) of extra tck > clocks before every DR scan that accesses the target memory bus through > the DAP_MEMAP. > This makes it possible to increase the jtag_khz, tested with JLink at > 12MHz, improving total speed. > > Contents: > + change signature for adi_jtag_dp_scan and adi_jtag_dp_scan_u32 to use > swjdp_common_t *swjdp instead of arm_jtag_t *jtag_info > + change SWJDP_IR/DR_APACC to DAP_IR/DR_APACC to conform with ARM_ADI docs. > + add swjdp->memaccess_tck field and code for extra tck clocks before > accessing memory bus > + Set default memaccess value to 8 for Cortex-M3 > + Add dap memaccess command > > Tested with STM32 andOMAP3530 for several weeks, no known problems. > > This should apply and build cleanly against trunk. > > Regards > Magnus
Applied patch. Looks pretty good. Except on startup I see a couple errors: $URL: svn://localhost:36903/openocd/trunk/src/openocd.c $ 500 kHz Error: J-Link command EMU_CMD_VERSION failed (-110) Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a Error: J-Link command EMU_CMD_VERSION failed (-110) 470 kHz <--- I set this in gdbinit since it was my previous upper limit target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000200 500 kHz 600 kHz I have gone up to 600 khz so far with no overruns. This is with 8 mhz stm3210e-eval with default clocking. How fast can I go? 12000 khz ...? Well, looks like I can maybe do "jtag_khz 1200" OK. Started at 12000 and worked down until it worked. Transfer to flash using command "lo a.out" reports a speed of 12 KB/Sec (for must a demo small program). Not sure what speed is good and what is bad. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
