On Donnerstag, 1. März 2018 07:27:49 CET Christopher Head wrote: > On Thu, 1 Mar 2018 00:12:12 +0100 > > Tomas Vanek <tom_...@users.sourceforge.net> wrote: > > We should also focus to a question why algo flashing is broken on > > FTDI. Some non STM devices (e.g. Kinetis) work with very similar algo > > just perfectly on FTDI or any other adapter. > > Sure. If someone could fix algorithm-based flashing, I would love to > use it! I’m not convinced it will make things any faster for my > specific set of hardware, but as long as it’s not broken and not > slower, I don’t really care, and I understand it does make things > faster for some people. > > > WAITs are very strange. It looks like the stalled access to flash > > blocks also JTAG access to RAM. > > And SWD access doesn't suffer this silicon bug... who knows... maybe > > some NOPs in algo busy wait loop would fix it. > > BTW The programming algo should avoid bus stalling, shouldn't it? > > I was wondering about this.
It's not really all that wonderous, since it's the DAP that stalls, and the DAP is single-issue. So of course once you run into a WAIT condition, it will only clear when the DAP has completed the access that caused it, and to complete it, you have to, well, wait. Note that when you receive the WAIT, it is the _previous_ access that is still pending, not the one you received the WAIT for. > The second data point is this: when using the algorithm-based approach, > I attached an oscilloscope to TDO coming out of the F7. I was very > surprised to see it *tristate* from time to time (at least, I’m pretty > sure it tristated—it had a very slow rise time and settled to a voltage > somewhat below VDD). I didn’t manage to correlate the time of the > tristate to any particular higher level activity, but it definitely > happened quite frequently during a programming operation and looked > very weird. I’m pretty sure it didn’t happen during direct programming, > only algorithm-driven programming. I found this suspicious, but again, > didn’t look into it too much as the direct approach was very fast. TDO just get's tristated when the target is not driving it, i.e. if you're not in SHIFT-IR/DR state. I have the same behaviour on the i.MX8MQ I'm currently working with. > > What OpenOCD version do you use? It looks like your version misses > > Matthias' WAIT handling > > if you get such errors like algo timeout. I don't think algo-timeout has to do with the DAP stalling. Isn't algo-timeout just that the algorithm running on the core is not reporting back to the debugger? The debugger is waiting for the target to execute a breakpoint so that it gets back control, right? > It was head of master from somewhere in the last week or two. I can > look up the exact commit ID tomorrow if you want. WAIT is included in 0.10.0 BR, Matthias ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
