Hmm, it seems strange that it returns an ACK_WAIT on the first try. It'll probably be a good idea to read the errata myself as well.
I will start experimenting today or tomorrow, but as of now I'm not sure how to get libswd up and running. Specifically I don't know how to tell it with which device to open for communication. Regards, Ákos On 13 March 2012 10:46, CeDeROM <cede...@tlen.pl> wrote: > 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
