On Mon, Mar 09, 2009 at 06:15:40PM +0100, Freddie Chopin wrote:
> I've sent you the sch, if the list wants, I can post that here too.

I see.  Thanks.
> 
> 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:

I have reviewed that list.  I just didn't cite it in an attempt to be
brief.

Some of those would provide usable tests, but they'd fall down when faced
with a Primer2, which might be supported one day.  The Primer2 has SRST
wired the way the standalone RLink does, yet has many of the differences
you listed in common with Primer1.

> 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...

I can write directly to the port control registers in the ST7.  So I am
limited only by the ST7 hardware and by what makes sense to drive without
fighting another driver somewhere.

The thing with that, however, is the same Primer2 issue which prevents
most of the listed differences from being used, unfortunately.


> 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 thing is that IO5 is wired to PA3 on the Primer1 and to PA5 on the
standalone RLink and the Primer2.  I only assert the lines on port A, as
appears to be done in the USB traces.

Asserting SRST via PB5 might work.  On both Primers and the standalone
RLink.  I may have to end up doing that.  It feels wrong, but it may be
the best way.  It would remove the need to detect.  I am going to pursue
this route.

It may be that this is exactly what you were getting at with that
paragraph.

The USB traces I saw did not touch port B at all, that I recall.  Not even
to read it.  Port B is different from the others in the ST7.  So far, it
doesn't appear that the difference is going to cause a problem.

> > 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? <:

I've inquired about that, and the answer was that it might show up after
1.0.  How soon, I do not know.  Actually, I think the answer may have
been more along the lines of that it wouldn't appear before then.

At the time of my inquiry, 1.0 hadn't been released yet.  On the other
hand, I haven't heard about it since; so I'm guessing SWD support won't
be there right away.

> 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.

The easiest way is probably to use RlinkCapab.exe, but here is a forum
post enumerating a few methods, including a link to RlinkCapab.

http://raisonance-forum.xsalto.com/viewtopic.php?id=2464
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to