I've sent you the sch, if the list wants, I can post that here too. lou.openocd...@fixit.nospammail.net pisze: > Weird. I think I might be able (using PB5 for feedback) to figure out > whether the adapter is a standalone RLink or a Primer and change the > initialization and reset code to do the right thing. So far, I haven't > figured out how to do that without spuriously asserting SRST as a side > effect of the test.
well, there are more differences than just the SRST - I only mentioned that because that is the main problem in the operation of "real RLink". All differences associated with ST7 chip are: 1. On primer PD3 has a 1M pullup, on RLink PD3 is N/C 2. On RLink PD1 drives RUN LED, on Primer PD1 is N/C 3. On RLink PD6 is tied to PC6 and PD7 is tied with PC7, and those lines are used to control 12V VPP for different devices, PD7/PC7 line has a 4k7 pullup, on Primer all of those are N/C 4. On RLink PF0 drives an unknown line with 4k7 pullup (tied with PE7 and PA2), Primer - all N/C 5. On RLink PF3 is used to measure 12V (probably shut down normally), through a 330k/100k divider (is that the right word?), Primer - N/C 6. On RLink PF5, PB4 and PA4 are DBGRQ and PF6, PB7 and PA7 - DBGACK, both lines with 4k7 pullup, on Primer PF5 and PF6 are used for ST7 programming, but normally are N/C without pullups, none of them are tied together on Primer 7. On RLink the OSCOUT pin is connected to OSCIN through a ~50R resistor, on Primer - N/C 9. On RLink PA3 and PB3 are RTCK (4k7 pullup), on Primer PA3 is tied to SRST, and PB3 is N/C 11. On Rlink PA5 and PB5 are SRST, on Primer PA5 is N/C, PB5 tied to PA3 12. On RLink PA6 drives an unknown line (tied with PB6) (4k7 pullup), on Primer - both N/C if the driver allows you to toggle any line, you don't have to check the SRST line, as there are many other lines tied together - toggling PC7 and testing PD7 (they are tied together on RLink) is perfectly safe IMHO, maybe PF0/PE7/PA2, maybe DBGRQ, maybe DBGACK, PB6/PA6... and is there a need to detect the device after all? can't the other SRST lines be an input on all variants? this way they wouldn't make a difference... > The schematic for the Primer2 agrees with what you said about PA5 > connecting to PB5. Maybe somebody made an error with the Primer1 and > just went with it. I could guess all day, but it would do little good. > The Primer2, since it uses SWD and not JTAG, tells us nothing about > RTCK. BTW what are the chances for SWD support in OpenOCD? <: > So, to say the same thing a different way; on Primer1, PA3 is SRST and > PA5 is NC. On a standalone RLink, PA3 is RTCK and PA5 is SRST. In either > case, PB5 is connected to SRST. Is all of that correct? yes, details on the sch and above > If there is no way to test which PA pin is SRST without spuriously > asserting SRST, I'll need another way of making the identification. > Maybe the serial code will help. My Primer1 has "dngWNYe" followed by 8 > numeric digits. It could be that those 7 characters contain information > about the dongle, and might tell us which line SRST is supposed to be. > Either that, or it's an opaque string which means nothing other than > it's an RLink, which would be of no help for this. > > The rlink driver in OpenOCD doesn't currently provide for printing the > serial code, but I can certainly add something to print it when > debugging output is requested. Windows users can, of course, use RIDE > (or its underlying tools) to get it. So if you or someone else can > reply with the serial for one or more standalone RLinks, that might be > helpful. if the info above in in the sch is not enough, tell me how to get that S/N on Windows and I'll provide you with a number for two RLinks and two Primers. 4\/3!! _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
