But HSE will not be always availabe. I found some code will make programming slow: In src/target/cortex_swjdp.c: /* Danger!!!! BROKEN!!!! */ scan_inout_check_u32(swjdp, SWJDP_IR_DPACC, DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); /* Danger!!!! BROKEN!!!! Why will jtag_execute_queue() fail here???? R956 introduced the check on return value here and now Michael Schwingen reports that this code no longer works....
https://lists.berlios.de/pipermail/openocd-development/2008-September/003107.html */ if ((retval=jtag_execute_queue())!=ERROR_OK) { LOG_ERROR("BUG: Why does this fail the first time????"); } /* Why??? second time it works??? */ scan_inout_check_u32(swjdp, SWJDP_IR_DPACC, DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); if ((retval=jtag_execute_queue())!=ERROR_OK) return retval; For USB tools, code above will slow down the programming speed. Can any one test it? Just call jtag_execute_queue once. Some tests on Versaloon(565KHz, normal mode): Windows(unfixed): 5.2KB/s Windows(fixed): 7.9KB/s Ubuntu(fixed): 9.6KB/s Amazing to see that Ubuntu is so much faster than Windows when doing the same operation. 2009-02-28 Best Regards, Simon Qian SimonQian([email protected]) ---- www.SimonQian.com 发件人： Spencer Oliver 发送时间： 2009-02-28 06:08:54 收件人： '�yvind_Harboe'; 'openocd-development' 抄送： 主题： Re: [Openocd-development] STM32 flash programming performance > I've looked a bit more into STM32 flash programming > performance and most of the time is spent waiting for the > target to complete flash programming, i.e. it appears that it > is the *target* that is slow. > > Could this be the case? > > Have you tried turning on the PLL etc before programming? That is generally what i do, and as far as i remember what the ST bootloader does. Otherwise the device is running @ 8MHz, gets better when running @ 72MHz. you can then speed up the jtag, instead of using the initial 500kHz. Cheers Spen _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
