On Sun, Jan 11, 2009 at 06:31:30PM +0100, Jörg Krein wrote: > Hi, > yes you were right. > I gave it a try with sudo. > Emitting a reset command via telnet results in: > > > reset > JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, > Part: 0xba00, Version: 0x3) > JTAG Tap/device matched > JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, > Part: 0x6410, Version: 0x1) > JTAG Tap/device matched > rlink/rlink.c, 535: too many retries waiting for DTC status
Odd. That message means that the rlink chip (in the Primer) got set up and even ran some DTC command buffers (the scan uses them, and we see proper scan results there). The message, itself, means that a DTC command was issued, and the polling for completion even worked, but the status never became complete after 5 polls. DTC commands are how the rlink is told to do something with the JTAG lines. A command packet is written to a USB endpoint, and commands are issued on another endpoint pair to query completion status. Does this happen every time you run it? If so, in the same place (after the reset)? The answer to this predicates everything below to some extent. I've seen this error during development, and running it again has always cleared it up, except when it was due to buggy DTC code. I haven't seen it in a long time. If it does happen every time; what if you look at src/jtag/rlink/rlink.c at around line 511 where it says "for(i = 5;;)" and change the 5 to a larger number? You should be able to make it arbitrarily large, as doing so just means that it will take longer to get this timeout error. If setting it to, say, 10 (or 100 or whatever), clears up your problem, we can change it in svn. I put 5 there, as I never seemed to need more than 3 on my (Ububntu) system. That test just wonders whether your kernel or USB host driver is managing to cram more bulk packet reads into a 1ms frame than mine is. Though how it could do that, I don't know, since it has to get a result before it issues the next poll. That polling loop assumes there'll be a millisecond or so between polls, so it doesn't insert its own delay. Usually, the poll will indicate completion pretty darn soon. Are you running through any hubs? I am running through an unpowered USB 1 hub just fine. > > Maybe I used the wrong board config? > I started with: > openocd -f interface/rlink.cfg -f > /usr/local/lib/openocd/board/stm32f10x_128k_eval.cfg I tested with that exact command line and got the following. JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3) JTAG Tap/device matched JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1) JTAG Tap/device matched target state: halted target halted due to undefined, current mode: Handler HardFault xPSR: 0x01000003 pc: 0xfffffffe Now what I don't know is whether that is the desired result (my target is not running actual code). But it is certainly different from yours. > Is there a special config for the Primer 1? > I not yet used with the new config system. I've been using something very similar. In fact, if you remove the "/usr/local/lib/openocd/" from the second config file path in your example, it is identical. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
