Hello Simon, thanks for explanation, it seems versaloon does pretty similar
stuff to libswd itself except libswd being external library with generic
interface to bistream in/out to work with any interface that is ft2232
based kt-link.
It looks that versaloon does not use sticky error signalling if you can
simply retransfer operation without error handling..?
Could you please tell exact algorithm in steps on how to perform mem-ap
read/write?
The problem I am working on currently is handling errors on series of
queued operations which should have great impact on performance by design,
yet it is harder to implement...
Best regards :-)
Tomek
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Mar 13, 2012 1:31 PM, "simonqian.openocd" <simonqian.open...@gmail.com>
wrote:
> **
> About error handler of SWD, I think it's much easier to put the retry code
> in SWD driver.
> If return value of every transaction must be examined, it will be a great
> reduce to performance.
> But it seems no solution for this. For bitband SWD, SWD driver must check
> result of every transaction, and for versaloon, SWD driver can be simpler.
> And in SWD transaction code(adi_v5_swd.c), high level error handler should
> be processed, which is stickyerr.
>
> ------------------------------
> simonqian.openocd
>
> *From:* simonqian.openocd <simonqian.open...@gmail.com>
> *Date:* 2012-03-13 20:03
> *To:* CeDeROM <cede...@tlen.pl>; Akos Vandra <axo...@gmail.com>
> *CC:* openocd-devel <openocd-devel@lists.sourceforge.net>
> *Subject:* Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
> Hi CeDeROM:
>
> Actually, when I implement SWD support for OpenOCD, I didn't get into much
> troubles.
> What I did is:
> 1. add SWD drivers according to the specification
> Versaloon firmware can do SWD re-transaction if SWD_ACK_OK is not
> returned, of course there is a max retry count.
> 2. didn't call JTAG specific functions in SWD mode, below is the list.
> jtag_init_inner(which will run a device detect algorithm on JTAG), tlr
> reset(because I didn't change the reset script)
> 3. make adi_v5 layer transport independent
> I added queue_dp_scan in dap_ops structure.
> 4. some minor fix, which is not vital, eg:
> I call
> swd_add_sequence((uint8_t*)jtag2swd_bitseq, sizeof(jtag2swd_bitseq) * 8);
> instead of
> jtag_add_tms_seq(8 * sizeof(jtag2swd_bitseq),
> jtag2swd_bitseq, TAP_INVALID); because JTAG function is not available in
> SWD mode, of course these 2 functions does the same in lower level.
>
> If you look into my patch, it only does above.
> adi_v5_swd.c maybe different, because actually it's originally copied from
> adi_v5_jtag.c, and OpenOCD has some modification in later commit in
> adi_v5_swd.c, and I didn't follow because original code is stable.
>
> About sticky error handler, I use the same method as JTAG, the difference
> is that when clear sticky error, use SWD method.
>
> Note that in ahbap_debugport_init, if SWD is sellected, besides
> STICKERR clear(different than JTAG procedure), dap_queue_idcode_read must
> also be called after dap_to_swd.
>
> ------------------------------
> simonqian.openocd
>
> *From:* CeDeROM <cede...@tlen.pl>
> *Date:* 2012-03-13 17:46
> *To:* Akos Vandra <axo...@gmail.com>
> *CC:* openocd-devel <openocd-devel@lists.sourceforge.net>
> *Subject:* Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
>
> 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
