Spencer Oliver wrote: > On 08/01/13 07:52, Brent Roman wrote: >> Spen, >> >> Yes, I could see where you would have liked to have a target specific >> method for reading a word from the DCC. >> That would have avoided some code duplication. >> >> Note 1: >> I don't see any code that lets the the ST-Link interface write 16-bit >> words atomically. This requires that it one write just the low byte >> when resetting the "busy" LSB of the DCC. If you just try overwriting >> the whole 16-bit word, the target usually slips in its next write before >> the relatively slow JTAG host zeros out the high byte. >> There probably should be a comment about this added to >> stm32_stlink_dcc_read() >> > > It is currently not possible todo real 16 bit writes at all on the > stlink. The stlink firmware will probably do two 8 bit writes, so it > may be worth just writing a single 8bit to clear the busy bit. > > You should not need to modify the target dcc lib. Yes, that's precisely what the patch I emailed ended up doing -- a single 8-bit write to clear the Busy bit. I'll add comment as to why, as it is not obvious.
As I said, you may do what you will with my improvements to the dcc target lib. > >> Note 2: >> After further testing, I discovered that DCC commands output at the top >> of the 'C' main() would appear to be missed by the host. Adding a 150ms >> delay in the target "fixed" this, but I wasn't pleased. >> The real problem is that the DCC busy bit was coming up set, so the host >> would misinterpret the zero in the high byte as a TRACEMSG command, >> which would be followed by the trace number. That would get the protocol >> out of sync. >> > > If you look at the std cortexm implementation you will see it > clears/saves/restores the DCB_DCRDR register so you do not get this > problem. > > The stlink version would have todo something similar. Ahh. Yes, now I see that. Great. I'll incorporate something similar into the ST-Link version. Thanks. > >> A better fix is to have the target clear the DDC-link busy bit a the top >> of its 'C' main(). >> Theoretically, this is still a race. Can one assume the target will get >> to its 'C' main() before the host reads its DCC? >> If not, it would seem that the "correct" approach might be for the host >> to also clear the DCC busy bit on target reset. >> >> What would be the best way to do that? >> >> Despite all the above, it now seems to work well in practice. >> I'd be very pleased if you'd merge this patch. Thank you. >> > > Can you upload to gerrit for review? Did you not write: Until the above happens i am happy to merge this patch, unless you can find time to do the above that is. I thought you'd offered to merge the patch yourself, as it was something "already on your list" Be that as it may, I will add the save/restore logic and resubmit it to the list in the next couple days. As I mentioned in my first mail, getting it rebased and into gerrit will take a couple months. I'm doing this work because I thought it would be convenient to support a firmware development project with a short fuse. It will be at least eight weeks before I "come up for air" from that. - brent > >> - brent >> >> P.S. I've attached an optimized version of dcc_stio I call dccput (as >> it does not do any input) >> Do with it what you will. Mainly, I just hoisted invariants out of >> inner loops. >> >> P.P.S. What does hla stand for? >> > > High Level Adapter > > Spen -- Brent Roman MBARI Software Engineer Tel: (831) 775-1808 7700 Sandholdt Road, Moss Landing, CA 95039 mailto:[email protected] http://www.mbari.org/~brent ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
