On Wed, Mar 11, 2009 at 09:57:57PM +0100, Freddie Chopin wrote: > ok than, I've done some more testing with real RLink this time. the > results are exactly the same as for Primer1 - so generaly RLink works > fine now...
Yay! :) > > BTW - RLink is pretty slow... compared to my FT2232 based JTAG it is > exactly 5 times slower (i compare the time of 100k code upload, same > jtag_khz, same target - cortex-m3). with standard 1MHz speed, the upload > speed is about 1kB/s, and with FT2232 based interface it is 5-6kB/s. The RLink as implemented can only actually operate at a certain number of speeds. Specifically 375k, 2181.82k, 3000k, and 12000k. Selecting another speed selects the next lower one. So that's about half of your slowdown right there. You think you're signalling at 1000k, but it's really 375k. And even that isn't the worst bottleneck. The worst bottleneck comes from limitations imposed by the firmware in the ST7 chip in the RLink dongle, which is undocumented. And then there are some pretty restrictive hardware limitations in the ST7 as well. I have already done as much as I can to speed things up, and am actually doing some fancy stuff to make it as fast as it is, considering what is available to work with. Slow is better than nothing, which is what we had before. If anybody thinks they can do it better than I did, they are welcome to. I just wanted to have a way to load an image into a Primer at all without having to run Windows or mess about with BOOT0 and the UART or desolder the RLink chip and flylead in a proper JTAG header. Any other functionality ( including standalone RLink support, which I was happy to add to make it more broadly useful), is gravy. > upload is just a minor issue, as you don't upload that much code with > JTAG that offen, but - stepping through code, or pausing the core is > pretty laggy too. what I mean is that 1 step usually takes about 5-10 > (up to 20 sometimes while in ISRs) seconds with RLink (and that is > annoying), while with FT2232 it is 'a blink of the eye (which is not > annoying at all). If anybody has an idea of what to look for, I'll look for it. My hunch is that this is related to the above limitations. Specifically, issuing any command buffer (instructions regarding what to shift out to or in from the TAP) requires explicit polling via USB to see when it is complete, and debugging seems to entail a lot of such commands. It's more complex than that, but that conveys the basic idea. I agree that having to wait seconds to step is painful. It would be an impetus to either use a different JTAG adapter or to use Raisonance's software. The latter is obviously not an option for me, as I do not run Windows. > > i also get some mystical errors and warns almost all the time in the > background: > > Error: SWJ-DP STICKY ERROR > Error: dcb_dhcsr 0x30003, nvic_shcsr 0x20800, nvic_cfsr 0x0, nvic_bfar > 0xe000edf8 > Warn : Block read error address 0x4e306078, count 0x1 > > exactly the same code with the same target but with FT2232 gives the > same errors and warns all the time, but the steps take 4-5sec max > (usually about 2-3sec), and there is no significant difference when > stepping through the ISR. If not for the fact that you get the same messages with another adapter, I'd be worried, since I got similar messages when things were broken during development. Albeit earlier in the process. Like during initialization. Fortunately, whatever this is, is not peculiar to the rlink driver. The slowness has probably been explained above. > > Anyway - a great step has been made, as now both primer and real RLink > are supported and are operational! Thanks for your help with that. Tracing out the standalone RLink schematic was critically important for that success. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
