Hey Akos! :-)
It would be too beautiful to be that simple, reading DRW initiates memory
read operation and it always returns ACK=WAIT (see ADIv5), then we need to
clear the sticky errors otherwise we get FAULT ACK, then we should read
RDBUFF with read result. But:
1. Polling READOK flag does not make sense it we need to read anything else
(CTRL/STAT) just after MEM-AP access.
2. Writing to DP register discards MEM-AP operation.
3. We need to reissue DRW read, it returns ACK=OK then (unless TAR has
changed due TAR autoincrement which might be dangerous in our case).
4. We need to read memory vale from RDBUFF.
5. It is also important to add dummy data phase on each ACK!=OK otherwise
protocol error occurs.
This works for me, after dozens of trials. If you think this can be done
simpler show me and Im delighted to implement simpler and more cleear
solution :-)
It is very important to create abstract solution in OpenOCD that will setup
transfer, perform transfer and handle potential errors then retry if
necessary. Program should not be left in unknown state or crash on error..
Best regards,
Tomek
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Mar 13, 2012 10:30 AM, "Akos Vandra" <axo...@gmail.com> wrote:
> Hi!
>
> I have just read through adiv5.1, and my understanding of the read
> operation is somewhat different:
>
> I understood that after you read DRW register, it should return an
> ACK_OK, with unpredictable data. And on the next read of the register
> (even with TAR changed) it returns the data of the previous read
> operation, and issues the next request on the bus. If you do not want
> to issue another read, just read the RDBUFF register of the DP
>
> So in order to read address 0x1234 and 0x5678, you:
>
> Set up mem-ap, tar = 0x1234
> Read DRW, get an ACK_OK (let's presume the read takes a lot of time)
> set up mem-ap, tar=0x5678
> Read DRW, get an ACK_WAIT (last read is still pending).
> Read DRW, get an ACK_WAIT (...)
> ....
> (Read completes)
> Read DRW, get an ACK_OK. Now the SW issues a read to 0x5678, and
> returns the data at address 0x1234.
> (Read completes fast)
> Read RDBUFF, get an ACK_OK with data at address 0x1234.
>
> With writes, you get an ACK_OK first, and then on the next write (if
> the previous completed) you might get an ACK_FAULT, but that is
> because the first write operation failed for some readon (for ex.
> peripheral was not powered on, and generated a bus fault).
>
> Please say how this sounds, I'll look up the exact chapter numbers in
> the docuementation, if needed.
>
> Regards,
> Ákos
>
>
> On 13 March 2012 09:40, CeDeROM <cede...@tlen.pl> wrote:
> > 2012/3/13 Sven Krauss <sven.kra...@web.de>:
> >> sorry for my long time of inactivity doe to other jobs. A while ago I
> send a
> >> patch making arm_adi_v5.c independent from transport layer. I created a
> >> third solution:
> >> To preserve the performance I changed the interface to the transport
> layer.
> >> Both, dap_queue_ap_write and dap_queue_ap_read gets a pointer to a data
> >> array not a single value. The adi_v5_jtag now implements the loop
> reading
> >> the registers via jtag transport layer. So other transports like SWD can
> >> implement it's own efficient method reading a register multiple times.
> >
> > Yes, double pointers (or pointers array as you state) are mandatory
> > when executing/operating on eqneueued elements from the past and when
> > we don't want to flush the queue on each read, I found that out too
> > :-) I have considered that, but I don't want to change the API unless
> > absolutely necessary, so I try to find some other solution first, if
> > not possible, we need to change the API slightly.
> >
> > Anyway, the pointers will increase the efficiency, while the main
> > problem right now is the error handling and retry by the OpenOCD
> > itself... I hope anyone will take the challenge and implement it in
> > OpenOCD, until then I am working on error handling and retry at the
> > libswd/transport level, which seems to be a circus, but also seems it
> > started to work recently :-)
> >
> > Best regards :-)
> > Tomek
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
> >
> ------------------------------------------------------------------------------
> > Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> > _______________________________________________
> > OpenOCD-devel mailing list
> > OpenOCD-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
