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
Date: 2012-03-13 17:46
To: Akos Vandra
CC: openocd-devel
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
