Re: [Openocd-development] SWD progress
Good news - I have managed to perform bidirectional communications with the STM32(Primer2) using ft2232h device (kt-link) + libswd incorporated into urjtag using its drivers! I had some hard time recently caused by incompetent people at ARM writing documentation - even most up to date documentation is sooo buggy: -APnDP should be 0 not 1 on idcode read -there is an additional IDLE state required after synchronous reset/dap_select sequence, but there is no word about it on the documents (aarrgggGHH^WT^#@ET^!T!^! this stole some time from me) -it is written so that most of the diagrams are partialy msb-first and some lsb-first on the same timeline and this is confusing -adi documentation dissaperared from their repository -because no logic analyzer i was not able to compare my signalling with one generated by rlink but the second generates lots of short and fast bursts of bits I did not even imagine ARM documentation to be that bad. Anyway, the work should accelerate now as most of the libswd is verified and functional :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
On Wed, Jan 12, 2011 at 8:52 AM, David Brownell davi...@pacbell.net wrote: From: Peter Stuge pe...@stuge.se Subject: Re: [Openocd-development] SWD progress To: openocd-development@lists.berlios.de Date: Tuesday, January 11, 2011, 11:06 PM simon qian wrote: SWD in Versaloon is based on operation. For example: A read operation consists of : 1. Host send the 8-bit command, and trn 2. read 3-bit ack 3. read the 32-bit data and 1-bit parity 4. host send the last trn So Versaloon can do some error handler. Tomek, does it sound like this is similar to what libswd outputs? Correct :-) These are the basic bus operations, wehere trn and parity bit is also an operation in libswd for easier implementation (also bitbang/bistream flush can be used from char array). Data can be directly queued up on the *cmdq (command bidirectional queue) or first bitstream can be generated for those operations and then queued up on the *cmdq - there are helper functions already implemented that realize this bistream, so no need to write them from scratch - ie. you only need to provide addres, operation type and access port and helper function will build request - then the request byte can be put on the queue. This way we can put data on the queue and have good overview of what is happening on the bus (swd-viewer), also something like svf record can be done, wehere all transactions are stored on the queue and then flushed out to file and then replayed with external software. Sounds like a bit-level description of most any SWD wire transaction... If versalon driver needs packey payload anywas and does not construct it itself, then you can use libswd helper functions to easily create those data. If so it perfectly matches current libswd abilities, but the problem also might occur when it is the cable itself that constructs the bitstream from parameters like address, access port, etc. In that case it might be easy to abstract libswd/versaloon. Exactly! I am aware that still libswd is not yet functional but it will be in a short time. Also this is good time to request functionalities :-) How is this not already done in the SWD transpsort defs? Implementations of the SWD ops to read/write registers must do those bitop sequences as driver ops. The trick is that libswd can be standalone, it was written for another purpose, but the integration with other utilities is critial, so I have created something like abstraction layer - where there are functions that can do TRN, BIT8 read/write and BIT32 read/write. The trick is to have as low functions as possible that could flush the queue out/into physical driver (or anything other utilizing existing higher level drivers). TRN must be separate function to work on the interface buffers. bit shift can be input or output and done from char and int data type, so I have created two functions that will flush n-bits, lsb/msb-first from char and int type. These functions are driver specific, located in external file and separate for openocd, urjtag and others.. please tahe a look at libswd_drv.c but these functions are still open for constructive criticism as work in progress (unfinished) :-) I hope this libswd organization is not too complex and in some ways comfortable - if it prove itself, maybe after some modifications (and lots of bugfixes), these utilities would be able to easily create other serial transports such as spi, i2c, 1wire, and many others using exiting cables that we already own :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
For SWD transaction layer, only 3 operation is needed. 1. initializaion/finalization/config(set trn) 2. output sequency on SWD, which is used to make adi into SWD mode. 3. The other is the transaction itself, including read and write operation. Any other applicapable feature? 2011/1/12 Tomek CEDRO tomek.ce...@gmail.com On Wed, Jan 12, 2011 at 8:52 AM, David Brownell davi...@pacbell.net wrote: From: Peter Stuge pe...@stuge.se Subject: Re: [Openocd-development] SWD progress To: openocd-development@lists.berlios.de Date: Tuesday, January 11, 2011, 11:06 PM simon qian wrote: SWD in Versaloon is based on operation. For example: A read operation consists of : 1. Host send the 8-bit command, and trn 2. read 3-bit ack 3. read the 32-bit data and 1-bit parity 4. host send the last trn So Versaloon can do some error handler. Tomek, does it sound like this is similar to what libswd outputs? Correct :-) These are the basic bus operations, wehere trn and parity bit is also an operation in libswd for easier implementation (also bitbang/bistream flush can be used from char array). Data can be directly queued up on the *cmdq (command bidirectional queue) or first bitstream can be generated for those operations and then queued up on the *cmdq - there are helper functions already implemented that realize this bistream, so no need to write them from scratch - ie. you only need to provide addres, operation type and access port and helper function will build request - then the request byte can be put on the queue. This way we can put data on the queue and have good overview of what is happening on the bus (swd-viewer), also something like svf record can be done, wehere all transactions are stored on the queue and then flushed out to file and then replayed with external software. Sounds like a bit-level description of most any SWD wire transaction... If versalon driver needs packey payload anywas and does not construct it itself, then you can use libswd helper functions to easily create those data. If so it perfectly matches current libswd abilities, but the problem also might occur when it is the cable itself that constructs the bitstream from parameters like address, access port, etc. In that case it might be easy to abstract libswd/versaloon. Exactly! I am aware that still libswd is not yet functional but it will be in a short time. Also this is good time to request functionalities :-) How is this not already done in the SWD transpsort defs? Implementations of the SWD ops to read/write registers must do those bitop sequences as driver ops. The trick is that libswd can be standalone, it was written for another purpose, but the integration with other utilities is critial, so I have created something like abstraction layer - where there are functions that can do TRN, BIT8 read/write and BIT32 read/write. The trick is to have as low functions as possible that could flush the queue out/into physical driver (or anything other utilizing existing higher level drivers). TRN must be separate function to work on the interface buffers. bit shift can be input or output and done from char and int data type, so I have created two functions that will flush n-bits, lsb/msb-first from char and int type. These functions are driver specific, located in external file and separate for openocd, urjtag and others.. please tahe a look at libswd_drv.c but these functions are still open for constructive criticism as work in progress (unfinished) :-) I hope this libswd organization is not too complex and in some ways comfortable - if it prove itself, maybe after some modifications (and lots of bugfixes), these utilities would be able to easily create other serial transports such as spi, i2c, 1wire, and many others using exiting cables that we already own :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Best Regards, SimonQian http://www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
On Wed, Jan 12, 2011 at 1:38 PM, simon qian simonqian.open...@gmail.com wrote: For SWD transaction layer, only 3 operation is needed. 1. initializaion/finalization/config(set trn) 2. output sequency on SWD, which is used to make adi into SWD mode. 3. The other is the transaction itself, including read and write operation. Any other applicapable feature? Output sequence in fact can be realized as series of writes with no parity bit - there is a helper function in libswd for this, 7 or 8 bytes is sufficient :-) I think initialization should be separate from TRN. Initialization is usually performed once while TRN very often. TRN requires some additional stuff to be done on the interface logic and it is device-specific, so it should have its own separate function. In UrJTAG there was only option to toggle JTAG signal pins and no others, so i had to create virtual signal, function wrapper and high-active and low-active bitmask specific to an interface. Some additional code recognized the virtual signal and then activated all high-active bitmask outputs on signal-high and low-active bitmask outputs on signal low. This however can (and will?) cause troubles on interfaces other than ft2232 where output buffers configuration cannot be easily set with a port bitmask switch (ie. some command or sequence), therefore if it is possible we should create sepratate function for making TRN switches - one function is sufficient, maybe a null pointer to a function in necessary. Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
Hi, I'm back for SWD, I have about 3-5 weeks holiday(hope my company will not call me back at holiday). So I can prepare for the Versaloon SWD driver in OpenOCD. Is the SWD transport usable now in OpenOCD? I compile the latest OpenOCD, but with this error: adi_v5_jtag.c:448: error: unknown field 'queue_dp_scan' specified in initializer queue_dp_scan is not defined in dap_ops. 2010/12/27 Tomek CEDRO tomek.ce...@gmail.com On Sat, Dec 25, 2010 at 3:17 AM, David Brownell davi...@pacbell.net wrote: Also, as promised some time back I'll soon commit my second SWD framework patch. The build issues with mainline OpenOCD have now been resolved; framework patch got updated; and it passes sanity testing. BUT ... SWD won't yet be fully functional in OpenOCD. The commit will mean: add some SWD driver support and debug a bit, and working SWD should be near... FT2232 on the way... I am getting back to document and put the libswd on its site at http://libswd.sf.net - the goal is to make it work with low level and high level drivers. As you can see the draft and its organization, we can expand its possibilities. I have seen your code for transport layer - it is very nice and elegant approach. As I am still making libswd work on UrJTAG I had also created something similar to transport (pretty independently, before reading the openocd code haha) and make it work with already existing cable drivers - this in general is done by flushing the swd_cmd_queue into the driver-specific data queue and flushing it into cable GPIO. Please share your ideas on how libswd could be expanded to easily implement high level commands as they are used with JLink or RLink, as I don't have experience with them. I have RLink but did not analyze its commands yet, I have some USB dumps however waiting :-) The swd_cmd_queue and driver bridge is implemented as four functions - two can shift data into target (mosi) with char (=8bit payload) and int (=32 bit payload) and two other in similar manner can shift out (miso) data from target. These functions are separated in libswd_drv.c (or libswd_drv_urjtag.c or maybe others, cable/program specific) so their body can be target specific - it can shift out bits from char arrays, but also can shift whole char/int payload. The other parameters of these functions is bit count to shift and the direction (LSB/MSB first). Maybe this organization is already enough to perform high-level commands that are cable specific? Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Best Regards, SimonQian http://www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
--- On Tue, 1/11/11, simon qian simonqian.open...@gmail.com wrote: I'm back for SWD welcome back! Is the SWD transport usable now in OpenOCD? Not yet; There's only infrastructure, not an entire transport (going down to driver level). I have two patches in the works: (a) init, e..g. call SWD driver init to set up WCR and such... (b) ft2232 based driver work for Luminary hardware. I compile the latest OpenOCD, but with this error: FWIW, my workspace builds error-free... adi_v5_jtag.c:448: error: unknown field 'queue_dp_scan' specified in initializer queue_dp_scan is not defined in dap_ops. Looks like a JTAG call. I just did a grep on my workspace and don't see that symbol. And it didn't appear to be in any patches either. Odd. build issues with mainline OpenOCD have now been resolved; framework patch got updated; and it passes sanity testing. BUT ... SWD won't yet be fully functional in OpenOCD. The commit will mean: add some SWD driver support and debug a bit, and working SWD should be near... FT2232 on the way... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
--- On Tue, 1/11/11, Tomek CEDRO tomek.ce...@gmail.com wrote: others). David provided his sources for SWD some time ago, I'll disagree a bit ... I've provided a bunch of mid-level infrastructure, but nothing I'd yet call (usable-as) SWD, since no driver is all there. That's on the way though. (I don't want expectations set wrong...) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
FWIW, my workspace builds error-free... adi_v5_jtag.c:448: error: unknown field 'queue_dp_scan' specified in initializer queue_dp_scan is not defined in dap_ops. Looks like a JTAG call. I just did a grep on my workspace and don't see that symbol. And it didn't appear to be in any patches either. Odd. Sorry, It was my another test patch. SWD in Versaloon is based on operation. For example: A read operation consists of : 1. Host send the 8-bit command, and trn 2. read 3-bit ack 3. read the 32-bit data and 1-bit parity 4. host send the last trn So Versaloon can do some error handler. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
simon qian wrote: SWD in Versaloon is based on operation. For example: A read operation consists of : 1. Host send the 8-bit command, and trn 2. read 3-bit ack 3. read the 32-bit data and 1-bit parity 4. host send the last trn So Versaloon can do some error handler. Tomek, does it sound like this is similar to what libswd outputs? In that case it might be easy to abstract libswd/versaloon. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
--- On Tue, 1/11/11, Peter Stuge pe...@stuge.se wrote: From: Peter Stuge pe...@stuge.se Subject: Re: [Openocd-development] SWD progress To: openocd-development@lists.berlios.de Date: Tuesday, January 11, 2011, 11:06 PM simon qian wrote: SWD in Versaloon is based on operation. For example: A read operation consists of : 1. Host send the 8-bit command, and trn 2. read 3-bit ack 3. read the 32-bit data and 1-bit parity 4. host send the last trn So Versaloon can do some error handler. Tomek, does it sound like this is similar to what libswd outputs? Sounds like a bit-level description of most any SWD wire transaction... In that case it might be easy to abstract libswd/versaloon. How is this not already done in the SWD transpsort defs? Implementations of the SWD ops to read/write registers must do those bitop sequences as driver ops. In that case it might be easy to abstract libswd/versaloon. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
Hello David! On Sat, Dec 25, 2010 at 3:07 AM, David Brownell davi...@pacbell.net wrote: http://files.tomek.cedro.info/electronics/arm/cortex/libswd/ I took a quick look. Two comments: Looks at first glance like it might help write some types of bit-level SWD driver (not ones that use higher level commands, as needed to support for example current JLink adapters.) I just got back :-) Never seen the high-level commands, but I guess those could be the part of a driver/transport. Queue helps debugging and viewing transmission progress. It can contain payload for bit-banging or simple data passing. We can create function pointer that will allow reading the idcode, lets say swd_idcode and it can point to libswd or driver specific function call. One disadvantage of ommiting the libswd is that we get inconsistent solution, because some drivers will have queue-log and others not. I think we should create some API for SWD access, and I can apply this api on libswd, so it could make high level and low level operations.. - is BSD-with-advertising clause compatible with the GPL? If not, there's an issue blocking use of that code with OpenOCD, since that seems to be the model for your license. This is new bsd license, not advertising (so called 4 point bsd license) that enforces placing authors on the promotional matherials, see http://www.opensource.org/licenses/bsd-license.php . It simply requires putting the copyright notice within legal notice and it does not allow to promote derived product with my name without my written permission, this is very simple and even more open than GPL because you can close source the results: * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * 1. Redistributions of source code must retain the above copyright notice, *this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright notice, *this list of conditions and the following disclaimer in the documentation *and/or other materials provided with the distribution. * 3. Neither the name of the Tomasz Boleslaw CEDRO nor the names of its *contributors may be used to endorse or promote products derived from this *software without specific prior written permission. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
On Sat, Dec 25, 2010 at 3:17 AM, David Brownell davi...@pacbell.net wrote: Also, as promised some time back I'll soon commit my second SWD framework patch. The build issues with mainline OpenOCD have now been resolved; framework patch got updated; and it passes sanity testing. BUT ... SWD won't yet be fully functional in OpenOCD. The commit will mean: add some SWD driver support and debug a bit, and working SWD should be near... FT2232 on the way... I am getting back to document and put the libswd on its site at http://libswd.sf.net - the goal is to make it work with low level and high level drivers. As you can see the draft and its organization, we can expand its possibilities. I have seen your code for transport layer - it is very nice and elegant approach. As I am still making libswd work on UrJTAG I had also created something similar to transport (pretty independently, before reading the openocd code haha) and make it work with already existing cable drivers - this in general is done by flushing the swd_cmd_queue into the driver-specific data queue and flushing it into cable GPIO. Please share your ideas on how libswd could be expanded to easily implement high level commands as they are used with JLink or RLink, as I don't have experience with them. I have RLink but did not analyze its commands yet, I have some USB dumps however waiting :-) The swd_cmd_queue and driver bridge is implemented as four functions - two can shift data into target (mosi) with char (=8bit payload) and int (=32 bit payload) and two other in similar manner can shift out (miso) data from target. These functions are separated in libswd_drv.c (or libswd_drv_urjtag.c or maybe others, cable/program specific) so their body can be target specific - it can shift out bits from char arrays, but also can shift whole char/int payload. The other parameters of these functions is bit count to shift and the direction (LSB/MSB first). Maybe this organization is already enough to perform high-level commands that are cable specific? Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
--- On Thu, 12/23/10, Tomek CEDRO tomek.ce...@gmail.com wrote: http://files.tomek.cedro.info/electronics/arm/cortex/libswd/ I took a quick look. Two comments: Looks at first glance like it might help write some types of bit-level SWD driver (not ones that use higher level commands, as needed to support for example current JLink adapters.) - is BSD-with-advertising clause compatible with the GPL? If not, there's an issue blocking use of that code with OpenOCD, since that seems to be the model for your license. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
Also, as promised some time back I'll soon commit my second SWD framework patch. The build issues with mainline OpenOCD have now been resolved; framework patch got updated; and it passes sanity testing. BUT ... SWD won't yet be fully functional in OpenOCD. The commit will mean: add some SWD driver support and debug a bit, and working SWD should be near... FT2232 on the way... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
On 2010-11-30 17:46, Tomek CEDRO wrote: Freddie, this is free and open source project, so no way to enforce rush from anyone on anyone, the work is in progress. I have managed to include this project somehow with my current tasks so I can put some more time into it, but I had to reschedule it from march too and it collides with some others tasks as well... The delays are unavoidable in a real world, and each second costs money - this is why I try to document it as well I can to spare this time for further implementation in openocd, so you wont have to reseach again :-) Nobody's forcing anything on anyone - I'm merely stating facts. OpenOCD is not normal open-source project, as most users have small knowledge about PC programming (e.g. me), that's why most of us OpenOCD-users can do nothing more than simple requests and bug reports... The fact that I can build OpenOCD myself is a huge success for me ; I'd really like to help with OpenOCD, but someone would need to tell me what to do (; In details like where, what mechanism / algorithm, what it should do. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
Hello Open'ers! :-) David, we will complement and complete our achievments soon and make them even better after intensive testing - still I hope You are the swd works coordinator in OpenOCD and you find some time to hint me with its internals.. as I dont have clue on how to debug yet? ;-P When my swd bitstream api os ready and working with urjtag i can get into openocd. As I mentioned I am working on pretty reusable API generating the SW-DP bitstream, wrappped into two-way queue, that could be wrapped into a target specific calls.. and some additional helper fumctions to make it easy :-) i will share the sources on http://swd.sf.net after some cleanup and i get the router at my new location (next week in worst case). Freddie, this is free and open source project, so no way to enforce rush from anyone on anyone, the work is in progress. I have managed to include this project somehow with my current tasks so I can put some more time into it, but I had to reschedule it from march too and it collides with some others tasks as well... The delays are unavoidable in a real world, and each second costs money - this is why I try to document it as well I can to spare this time for further implementation in openocd, so you wont have to reseach again :-) Best regards, Tomek ps/2: regarding the previous thread the openocd is not yet as stable as rock - it still need some improvements and features, what is clearly visible when looking at the patch aplication frequency. I think that more frequent build releases might help it more user triendly, but still there must be a person that could volountairly accomplish this task. Ps//3: damn xell phone :-P On 30 Nov 2010 17:01, David Brownell davi...@pacbell.net wrote: On 30 Nov 2010 08:46, freddie_cho...@op.pl wrote: ... Have you synchronized your work with that of Tomek Cedro? It should go the other way around. The only part of my work that's not yet been public is a driver that first needs test-time; OpenOCD integration has been on-going. Nobody has bothered asking any technical questions, though, or even commenting on the framework patch (with SWD transport). Not one technical suggestion has been offered. That's not how to work on community projects... The only other public SWD work has been Simon's,but that's not been aimed at OpenOCD mergability; more in the useful HW-specific prototype category. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
