Re: [OpenOCD-devel] Support for LPC1114?
Hi, Does the swd library commited in the OpenOCD? SWD driver of Versaloon is now included in OpenOCD, refer to /src/jtag/drivers/versaloon/usbtoxxx/usbtoswd.c, it's only 150 lines of code. I'm not sure how will SWD be implemented in OpenOCD. Or should I move SWD drivers to the swd library? simonqian.openocd From: CeDeROM Date: 2012-01-25 19:29 To: dave higton CC: openocd-devel Subject: Re: [OpenOCD-devel] Support for LPC1114? On Wed, Jan 25, 2012 at 11:40 AM, dave higton wrote: > Which is not supported: SWD or Cortex-M0? > > Are there plans to add support? Is anyone working on it? How > big a job is it? SWD is not yet fully implemented I am working on this enormous big job to create generic and software independend SWD implementation in form of a library [1] but hopefully heading towards end, there are some hacks to make flashing work at the moment with Versaloon [2] device and some other interface I am not familiar with look for the recent list archive you can give it a try :-) [1] http://stm32primer2swd.sourceforge.net/ [2] http://www.versaloon.com/ 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
[OpenOCD-devel] make arm_adi_v5.c transport independent
Hi, I have recently read libswd code and want to somewhat push the SWD progress. First modification should be to arm_adi_v5.c and/or adi_v5_jtag/swd.c, so that arm_adi_v5.c could be transport independent. I found both libswd and my SWD patch modify 2 main functions in arm_adi_v5.c, which are ahbap_debugport_init and mem_ap_read_buf_u32. ahbap_debugport_init should obviously be modified to initialize SWD if SWD transport is sellected. And mem_ap_read_buf_u32 should not call adi_jtag_dp_scan, or implement mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. 2 solutions: 1. In my SWD patch, I add queue_dp_scan to dap->op, and implement dap_queue_dp_scan to call dap->op->queue_dp_scan instead of JTAG ones. And queue_dp_scan is implemented in both jtag_dp_ops and swd_dp_ops. 2. In libswd code, 2 functions are implemented for mem_ap_read_buf_u32, which are mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. And they are called in mem_ap_read_buf_u32 according to the transport sellected. So the result is simple, choose one of the 2 methods above. Both are OK for me if we can make progress. And I can prepare the patch if any one want to try. simonqian.openocd-- 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
[OpenOCD-devel] 回复: Re: make arm_adi_v5.c transport independent
Yes, I know what you mean. It can be another choice. Thanks. Use static int adi_jtag_scan_inout_check_u32(struct adiv5_dap *dap, uint8_t instr, uint8_t reg_addr, uint8_t RnW, uint32_t *buffer, uint32_t count) instead of static int adi_jtag_scan_inout_check_u32(struct adiv5_dap *dap, uint8_t instr, uint8_t reg_addr, uint8_t RnW, uint32_t outvalue, uint32_t *invalue) simonqian.openocd 发件人： Sven Krauss 发送时间： 2012-03-13 15:59 收件人： openocd-devel 主题： Re: [OpenOCD-devel] make arm_adi_v5.c transport independent Hi, 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. I don't know if the patch works, but it should be easy to adapt. Best regards, Svenwhile Am 13.03.2012 05:30, schrieb simonqian.openocd: Hi, Attachment is the patch for the latest OpenOCD. Versaloon forum has been moved to http://groups.yahoo.com/group/versaloon/. Actually, there are many patches to implement SWD. I just want to find a start point, and original JTAG code is least affected. So I want first make OpenOCD transport independent, so that JTAG is also usable(and testable) and meanwhile SWD code can be commited. simonqian.openocd From: Peter Stuge Date: 2012-03-13 11:53 To: openocd-devel Subject: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent Hi Simon, simonqian.openocd wrote: > I have recently read libswd code Thank you very much for looking into this! > and want to somewhat push the SWD progress. > First modification should be to arm_adi_v5.c and/or adi_v5_jtag/swd.c, > so that arm_adi_v5.c could be transport independent. > > I found both libswd and my SWD patch modify 2 main functions in > arm_adi_v5.c, which are ahbap_debugport_init and mem_ap_read_buf_u32. Where can your most recent SWD patch be found? http://www.versaloon.com/doc/versaloon/doc_versaloon_openocd_urjtag.html has a patch from 2010-11-04, and unfortunately the versaloon.com Forum seems to be unavailable since some time. > ahbap_debugport_init should obviously be modified to initialize SWD > if SWD transport is sellected. > And mem_ap_read_buf_u32 should not call adi_jtag_dp_scan, or > implement mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. > > 2 solutions: > 1. In my SWD patch, I add queue_dp_scan to dap->op, and implement > dap_queue_dp_scan to call dap->op->queue_dp_scan instead of JTAG ones. > And queue_dp_scan is implemented in both jtag_dp_ops and swd_dp_ops. > 2. In libswd code, 2 functions are implemented for mem_ap_read_buf_u32, > which are mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. > And they are called in mem_ap_read_buf_u32 according to the transport > sellected. > > So the result is simple, choose one of the 2 methods above. I can't make a useful comment at this point, but I would like to look at the code and make a suggestion. > Both are OK for me if we can make progress. > And I can prepare the patch if any one want to try. Thank you for this effort. I will be very happy to test patches. //Peter -- 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-- 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___ OpenOC
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
> How would dp_scan work? OK, I know the vital problem. Yes, it's much more complex if implement SWD in bit-band mode. Because error should be processed in each SWD transaction. For versaloon, it's very simple, just because versaloon has a processor and do the error handling. So, SWD support of versaloon is stable for a long time and very easy to implement. I agree we should consider more for a generic SWD adaptor. simonqian.openocd-- 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
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 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" 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 wrote: > 2012/3/13 Sven Krauss : >> 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 chang
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
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 Date: 2012-03-13 20:03 To: CeDeROM; Akos Vandra CC: openocd-devel 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 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" 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 wrote: > 2012/3/13 Sven Krauss : >> 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 th
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
>> 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. >What happens when the retry count expires? OpenOCD shows an error, >but what state is the target in? Actually, versaloon will resend automatically, no error will rise in upper level. I can try to remove the resend code in Versaloon, and see what will happen. >> 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) >How does device detect and reset work using SWD? For JTAG: scan enough 1's after jtag reset and from the data read, IDs of all target devices are listed. For SWD: dap_queue_idcode_read will return the SWD_ID, so that target device can be detected. reset is simply to control srst pin, but for jtag, if trst_with_tlr is enabled, TLR is used. >> 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. >Can you say which commit your latest patch is based on? I really can't remember that, it's more than 2 years ago. But I can try to test it on the latest code in OpenOCD. >> About sticky error handler, I use the same method as JTAG, the >> difference is that when clear sticky error, use SWD method. >Does this fit also SWD? Actually, there is jtagdp_transaction_endcheck and swddp_transaction_endcheck, which will check the stickyerr. You can refer to swddp_transaction_endcheck, there is even some broken code in old OpenOCD: /* Danger BROKEN */ adi_swd_scan_inout_check_u32(dap, SWD_DP_DPACC, DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); /* Danger BROKEN Why will jtag_execute_queue() fail here R956 introduced the check on return value here and now Michael Schwingen reports that this code no longer works https://lists.berlios.de/pipermail/openocd-development/2008-September/003107.html */ I think SWD support should be added from high to low, some modification in my patch is only a work-around, but not a solution. Versaloon driver can also be added into libswd, or independent from libswd, it's not the vital point. The vital problem is that even now, OpenOCD code is too much JTAG dependent, so that it's not possible to add other transports, even if the transport layer is ok. I know which codes in OpenOCD are JTAG dependent. So if we can somehow make these codes transport independent under some common point of view, it will be easier for other to add their drivers. simonqian.openocd-- 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
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Like JTAG, sticky error is not process in JTAG drivers. I don't know why SWD driver should handle sticky error, I haven't received such reports. JTAG can support many target chips, but it doesn't mean that if we add CortexM support which has sticky error, we have to modify JTAG driver. I think so is SWD. > 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... For bit stream SWD driver, there is no way to solve it, because the return value of each transaction should be examined, for non SWD_ACK_OK result, but not for sticky error. >Could you please tell exact algorithm in steps on how to perform mem-ap >read/write? It's the same as JTAG in high layer(arm_adi_v5.c), but there is some difference in adi_v5_swd.c. I'll try to check the current adi_v5_swd.c to see if there is any problem. simonqian.openocd From: CeDeROM Date: 2012-03-13 23:18 To: simonqian.openocd CC: Akos Vandra; openocd-devel Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent 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" 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 Date: 2012-03-13 20:03 To: CeDeROM; Akos Vandra CC: openocd-devel 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 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
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Let's start from the most common points of view and make some most safe modifications first. I think the first thing can be done safely is to remove jtag_add_reset, in adi and cortex codes. There is no check for the current transport, and take JTAG as default. And if jtag_add_reset is called, there is chances that TLR reset will be used, which is not available in SWD mode. We can add queue_reset function in dap_ops, and implement reset method in adi_jtag and adi_swd. Or we can simply add a function to handle reset in arm_adi_v5.c code. Or we can disable TLR reset if JTAG is not sellected. But I don't prefer this. simonqian.openocd-- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
> I would prefer to create dedicated reset function in arm_adi_v5 if possible > to use existing dp/ap read/write functions, to keep dap_ops interface > functions as compact as possible, but if thats not possible the additional > member of dap_ops seems unavoidable :-) The reset function will control srst in SWD mode. The existing dp/ap read/write functions will not be called. > Do you need my support in this Simon? I would prefer to clean up the existing > code and prepare for merge into openocd master, then still work on queueing > mechanism / retry on existing queue to bring speed into reasonable level > better than presented (what it the avg speed of versaloon btw?).. but if > there are any more important tasks just let me know and Im here to help :-) You can save your time and prepare for libswd. What I need is the common points of view about how it should be implemented. Below is the speed when programming flash of stm32 using versaloon. For STM32 chips, it gets about 8KB/s - 12KB/s under SWD mode in OpenOCD. In vsprog, it gets about 35KB/s because vsprog uses a double buffer operation, which means data can be transmitted to ram of target stm32 via SWD while stm32 is doing the flash programming. simonqian.openocd-- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
OK, I find it's even not easy to add swd_reset.
Here is what I do:
In arm_adi_v5.c, seems simple:
void adi_v5_assert_reset(void)
{
if (transport_is_jtag()) {
if (jtag_reset_config & RESET_SRST_PULLS_TRST)
jtag_add_reset(1, 1);
else
jtag_add_reset(0, 1);
}
else if (transport_is_swd())
swd_add_reset(1);
}
void adi_v5_deassert_reset(void)
{
if (transport_is_jtag())
jtag_add_reset(0, 0);
else if (transport_is_swd())
swd_add_reset(0);
}
In core.c:
void swd_add_reset(int req_srst)
{
int new_srst = 0;
if (req_srst) {
if (!(jtag_reset_config & RESET_HAS_SRST)) {
LOG_ERROR("BUG: can't assert SRST");
jtag_set_error(ERROR_FAIL);
return;
}
new_srst = 1;
}
/* Maybe change TRST and/or SRST signal state */
if (jtag_srst != new_srst) {
int retval;
retval = interface_swd_add_reset(new_srst);
if (retval != ERROR_OK)
jtag_set_error(retval);
else
retval = jtag_execute_queue();
if (retval != ERROR_OK) {
LOG_ERROR("TRST/SRST error");
return;
}
}
/* SRST resets everything hooked up to that signal */
if (jtag_srst != new_srst) {
jtag_srst = new_srst;
if (jtag_srst) {
LOG_DEBUG("SRST line asserted");
if (adapter_nsrst_assert_width)
jtag_add_sleep(adapter_nsrst_assert_width * 1000);
} else {
LOG_DEBUG("SRST line released");
if (adapter_nsrst_delay)
jtag_add_sleep(adapter_nsrst_delay * 1000);
}
}
}
I didn't change the name of jtag_reset_config, jtag_set_error,
jtag_execute_queue, and even jtag_add_sleep.
Despite the jtag_ prefix, I can make things working.
Should I add a set of same functions with swd_ prefix?
simonqian.openocd--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
First patch to review: no call jtag_add_reset regardless of the transport selected. simonqian.openocd 0001-no-call-jtag_add_reset-regardless-of-the-transport-s.patch Description: Binary data -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Yes, I know how SRST should not be processed in DAP, but make the change you mentioned is too large for me to handle in OpenOCD. And it also risky because it affect too much in OpenOCD. In vsprog, I have the similar interface layer, which processes all signals to the target. SRST control in vsprog is in GPIO module, for example: interfaces->gpio.config(0, GPIO_SRST, GPIO_SRST, 0, 0); interfaces->gpio.set(0, GPIO_SRST); There is of course jtag and swd function, and can be called like: interfaces->jtag_hl.ir(); interfaces->jtag_hl.dr(); interfaces->swd.transact(); So it's very simple for me to add different transports and targets in vsprog. About double buffer operation in cortex-m targets. There are 2 buffers in working area of target chip, flash loader will do programming operations if one of them is filled with data. And while the flash loader is doing the programming, we can meanwhile download data into the other buffer. So if we select the right buffer size, we can get the max speed. For stm32, as I test on versaloon, it's about 35KB/s. simonqian.openocd-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
> So we should place that reset implementation using interface bitbang..? I currently use interface_jtag_add_reset(0, new_srst); to control srst in SWD mode. Although not best modular, but works with the least and safest patch. > So there is some code uploaded and executed on the target and that code use > ram buffers to store data for better efficiency..? Where can I read more > about this solution? Will it work with OpenOCD? Yes, the code you mentioned is called flash loader. You can read the codes at src/target/cortex-m3/cm3_stm32_fl.c and cm3_stm32f1.c under same directory. I don't think it will work with OpenOCD easily, but of course, it can work after some efforts. simonqian.openocd From: Tomek CEDRO Date: 2012-03-15 15:12 To: simonqian.openocd CC: Peter Stuge; openocd-devel Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent On Mar 15, 2012 3:15 AM, "simonqian.openocd" wrote: > > Yes, I know how SRST should not be processed in DAP, but make the > change you mentioned is too large for me to handle in OpenOCD. And it > also risky because it affect too much in OpenOCD. Ok then lets do it as you proposed if its already working :-) > In vsprog, I have the similar interface layer, which processes all signals > to the target. SRST control in vsprog is in GPIO module, for example: > interfaces->gpio.config(0, GPIO_SRST, GPIO_SRST, 0, 0); > interfaces->gpio.set(0, GPIO_SRST); > There is of course jtag and swd function, and can be called like: > interfaces->jtag_hl.ir(); > interfaces->jtag_hl.dr(); > interfaces->swd.transact(); > So it's very simple for me to add different transports and targets in vsprog. So we should place that reset implementation using interface bitbang..? The main advantage of this solution is to create and operate on signals at runtime.. > About double buffer operation in cortex-m targets. > There are 2 buffers in working area of target chip, flash loader will do > programming operations if one of them is filled with data. And while the > flash loader is doing the programming, we can meanwhile download data > into the other buffer. So if we select the right buffer size, we can get the > max speed. For stm32, as I test on versaloon, it's about 35KB/s. So there is some code uploaded and executed on the target and that code use ram buffers to store data for better efficiency..? Where can I read more about this solution? Will it work with OpenOCD? Best regards :-) Tomek CeDeROM, SQ7MHZ, http://www.tomek.cedro.info-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
OK, I have tested this patch with my other SWD patches, it works well.
But another code should be fixed too.
I want to query for how to fix it.
on "reset init" command, init_reset procedure in startup.tcl will be called:
proc init_reset { mode } {
jtag arp_init-reset
}
and then jim_jtag_arp_init_reset will be called to process "jtag
arp_init-reset".
But jim_jtag_arp_init_reset will call jtag_init_reset, which is not valid under
SWD mode.
I want to know how to fix it.
startup.tcl should detect current transport and call "jtag arp_init-reset" in
JTAG mode?
Or add a check in jim_jtag_arp_init_reset like below:
if (transport_is_jtag())
{
int e = jtag_init_reset(context);
if (e != ERROR_OK) {
Jim_Obj *eObj = Jim_NewIntObj(goi.interp, e);
Jim_SetResultFormatted(goi.interp, "error: %#s", eObj);
Jim_FreeNewObj(goi.interp, eObj);
return JIM_ERR;
}
}
simonqian.openocd
From: simonqian.openocd
Date: 2012-03-15 02:34
To: Tomek CEDRO
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
First patch to review: no call jtag_add_reset regardless of the transport
selected.
simonqian.openocd--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
So I implement it as below:
First add swd_init_reset:
int swd_init_reset(struct command_context *cmd_ctx)
{
int retval = adapter_init(cmd_ctx);
if (retval != ERROR_OK)
return retval;
LOG_DEBUG("Initializing with hard SRST reset");
jtag_add_reset(0, 1);
jtag_add_reset(0, 0);
retval = jtag_execute_queue();
return retval;
}
And in jim_jtag_arp_init_reset:
if (transport_is_jtag())
e = jtag_init_reset(context);
else if (transport_is_swd())
e = swd_init_reset(context);
I'm doing some tests, if it's OK I'll format a new patch.
And next patch will be to make arm_adi_v5 transport independent.
And then add the SWD driver layer.
Then enjoy SWD.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-03-15 23:03
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Yup, the easiest way to test thing without changing stuff with dependencies in
multiple places would be simply to create a wrapper for existing function that
will call original with _jtag suffix or new one with _swd suffix, just as I did
in case of memapreadu32. Changing functions inline would produce more work in
future so I would prefer to create a wrapper and additional function to leave
original untouched (except _jtag prefix)... is that ok for you Simon?
Best regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Mar 15, 2012 2:57 PM, "simonqian.openocd"
wrote:
OK, I have tested this patch with my other SWD patches, it works well.
But another code should be fixed too.
I want to query for how to fix it.
on "reset init" command, init_reset procedure in startup.tcl will be called:
proc init_reset { mode } {
jtag arp_init-reset
}
and then jim_jtag_arp_init_reset will be called to process "jtag
arp_init-reset".
But jim_jtag_arp_init_reset will call jtag_init_reset, which is not valid under
SWD mode.
I want to know how to fix it.
startup.tcl should detect current transport and call "jtag arp_init-reset" in
JTAG mode?
Or add a check in jim_jtag_arp_init_reset like below:
if (transport_is_jtag())
{
int e = jtag_init_reset(context);
if (e != ERROR_OK) {
Jim_Obj *eObj = Jim_NewIntObj(goi.interp, e);
Jim_SetResultFormatted(goi.interp, "error: %#s", eObj);
Jim_FreeNewObj(goi.interp, eObj);
return JIM_ERR;
}
}
simonqian.openocd
From: simonqian.openocd
Date: 2012-03-15 02:34
To: Tomek CEDRO
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
First patch to review: no call jtag_add_reset regardless of the transport
selected.
simonqian.openocd--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
I've sent the patch for review. And the patch for mem_ap_read_buf_u32 is ready and tested OK both on JTAG and SWD. Next will be adding the SWD drivers. I recommend to user the current JTAG queue functions. In my original SWD patch, I add SWD_SEQ and SWD_TRANSACT commands to jtag_command_type. And add the corresponding struct in jtag_command_container. Add swd_add_sequence, swd_add_transact_out, swd_add_transact_in. And corresponding implementations in driver.c. Implement the SWD codes in adi_v5_swd.c, and fix ahbap_debugport_init. What's more, we'll need a command to set trn of SWD. simonqian.openocd From: Peter Stuge Date: 2012-03-16 00:36 To: openocd-devel Subject: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent simonqian.openocd wrote: > I'm doing some tests, if it's OK I'll format a new patch. I think it looks fine. Am looking forward to the patch. I would suggest changing the Tcl command from jtag to e.g. transport while keeping backwards compatibility but outputing a warning whenever someone uses the old command, but that can be done later. //Peter -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Yes, these functions are in dap_ops structure. To implement SWD, nothing more than a dap_ops structure and a transport structure will be necessary. So, you mean use dap_ops struct as swd driver struct? A interface which supports SWD, will provide a dap_ops sturcture for swd operations? It's also OK for me, I can even write these functions in versaloon hardware. If we could define a common API for SWD, I can do the test ASAP. I found a swd_driver struct in swd.h, which seems much simpler. But I haven't tried using this driver. The driver has only 3 main APIs: int (*init)(uint8_t trn); int (*read_reg)(uint8_t cmd, uint32_t *value); int (*write_reg)(uint8_t cmd, uint32_t value); And current swd_dap_ops in adi_v5_swd.c simply calls these functions. simonqian.openocd From: Tomek CEDRO Date: 2012-03-17 18:15 To: simonqian.openocd CC: openocd-devel; Peter Stuge Subject: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent On Mar 17, 2012 8:40 AM, "simonqian.openocd" wrote: > Next will be adding the SWD drivers. In order to have generic driver for transport layer I have introduced TRANSFER and BITBANG methods to the interface structure. transfer can send in and out bitstream from the array of chars, array of chars is provided by transport-interface bridge, so the same function can be used in transport for different drivers. BITBANG is used to control interface port state, it can read and write to the port, specificaly driver then RnW/TRN buffers. These two functions are the minimal set of functions to implement any transport possible :-) > I recommend to user the current JTAG queue functions. Nope, that would create dependecy of transport on the openocd queue. OpenOCD queue should be left for internal use only (also jtag queue should be moved out from there into jtag transport). TRANSPORT is here to translate target commands (ie. mem-ap read) into interface sequences (ie. bitstream for generic drivers such as ft2232 or gpio and commands for inteligent drivers such as versaloon). LibSWD has its own internal queue and can handle DP/AP read/write and pass the result to the drivers. The design idea was to have swd working even on the gpio or parallel port with two resistor (maybe some diode) interface :-) Versaloon as the intelligent driver has also its own queue in the interface, target would simply send commands to the interface and interface will handle the dp/ap read/write. Transport structure use function pointers for this - jtag has its own (or should), swd has its own - selecting transport simply switches the function set and calls transport_select function from the set... The transport functions are defined in transport.h and it goes something like: DAP_IDCODE DAP_ABORT DAP_FLUSH DP_READ DP_WRITE AP_READ AP_WRITE This is all what is necessary to talk to the ADI using SWD. LibSWD get commands and translates it into operations that can be used by any interface, lets call it swd_generic transport - it requires at least two interface functions: 1 to transfer bitstream in efficient way, 2 to set the buffers for TRN. Versaloon can handle the commands itself so it can use another transport that simply pass the dap operations to the interface, lets call it swd_dedicated transport - in this case the inferface needs only one function that would pass the dap operations into/from the dedicated driver. The mentioned queue mechanism should be implemented in this place, at best in the versaloon interface driver, because different drivers can have different needs for buffering/enqueing.. This is clean and elegant solution huh..? :-) > In my original SWD patch, I add SWD_SEQ and SWD_TRANSACT commands to > jtag_command_type. > And add the corresponding struct in jtag_command_container. > Add swd_add_sequence, swd_add_transact_out, swd_add_transact_in. > And corresponding implementations in driver.c. > Implement the SWD codes in adi_v5_swd.c, and fix ahbap_debugport_init. I would recommend to put all this stuff into dedicated versaloon inferface driver and do not put any solution dependent code into arm_adi_v5 as this is neither part of the adi/target, nor swd transport itself... this would also allow designers to handle operations just as they like/need :-) > What's more, we'll need a command to set trn of SWD. This is done by the interface function bridge that use only transfer and bitbang generic calls. Please take a look at kt-link-swd.cfg and note "interface_signal add RnW 0xMASK" definitions. For versaloon things should be even simpler because it only gets dp_read and it handles the request itself, no need to handle TRN by the user.. however it would be also nice if versaloon provide bitbang interface in future to make it even more versatile :-) Best regards! :-) Tomek ps/2: greetings from a train, nice to have email access in pocket :-)-- This SF email is sponsosred by: Try Windows Azure f
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
I attached the patch for mem_ap_read_buf_swd, which looks like Tomek's patch. But the code it just same as JTAG ones. I'll later try implementing a swd_driver structure for Versaloon SWD driver. To Tomek: Do you have any supplement for swd_driver structure? I hope this job could be finished before 24th April, before which I can have enough time. simonqian.openocd From: simonqian.openocd Date: 2012-03-17 20:22 To: Tomek CEDRO CC: openocd-devel; Peter Stuge Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent Yes, these functions are in dap_ops structure. To implement SWD, nothing more than a dap_ops structure and a transport structure will be necessary. So, you mean use dap_ops struct as swd driver struct? A interface which supports SWD, will provide a dap_ops sturcture for swd operations? It's also OK for me, I can even write these functions in versaloon hardware. If we could define a common API for SWD, I can do the test ASAP. I found a swd_driver struct in swd.h, which seems much simpler. But I haven't tried using this driver. The driver has only 3 main APIs: int (*init)(uint8_t trn); int (*read_reg)(uint8_t cmd, uint32_t *value); int (*write_reg)(uint8_t cmd, uint32_t value); And current swd_dap_ops in adi_v5_swd.c simply calls these functions. simonqian.openocd From: Tomek CEDRO Date: 2012-03-17 18:15 To: simonqian.openocd CC: openocd-devel; Peter Stuge Subject: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent On Mar 17, 2012 8:40 AM, "simonqian.openocd" wrote: > Next will be adding the SWD drivers. In order to have generic driver for transport layer I have introduced TRANSFER and BITBANG methods to the interface structure. transfer can send in and out bitstream from the array of chars, array of chars is provided by transport-interface bridge, so the same function can be used in transport for different drivers. BITBANG is used to control interface port state, it can read and write to the port, specificaly driver then RnW/TRN buffers. These two functions are the minimal set of functions to implement any transport possible :-) > I recommend to user the current JTAG queue functions. Nope, that would create dependecy of transport on the openocd queue. OpenOCD queue should be left for internal use only (also jtag queue should be moved out from there into jtag transport). TRANSPORT is here to translate target commands (ie. mem-ap read) into interface sequences (ie. bitstream for generic drivers such as ft2232 or gpio and commands for inteligent drivers such as versaloon). LibSWD has its own internal queue and can handle DP/AP read/write and pass the result to the drivers. The design idea was to have swd working even on the gpio or parallel port with two resistor (maybe some diode) interface :-) Versaloon as the intelligent driver has also its own queue in the interface, target would simply send commands to the interface and interface will handle the dp/ap read/write. Transport structure use function pointers for this - jtag has its own (or should), swd has its own - selecting transport simply switches the function set and calls transport_select function from the set... The transport functions are defined in transport.h and it goes something like: DAP_IDCODE DAP_ABORT DAP_FLUSH DP_READ DP_WRITE AP_READ AP_WRITE This is all what is necessary to talk to the ADI using SWD. LibSWD get commands and translates it into operations that can be used by any interface, lets call it swd_generic transport - it requires at least two interface functions: 1 to transfer bitstream in efficient way, 2 to set the buffers for TRN. Versaloon can handle the commands itself so it can use another transport that simply pass the dap operations to the interface, lets call it swd_dedicated transport - in this case the inferface needs only one function that would pass the dap operations into/from the dedicated driver. The mentioned queue mechanism should be implemented in this place, at best in the versaloon interface driver, because different drivers can have different needs for buffering/enqueing.. This is clean and elegant solution huh..? :-) > In my original SWD patch, I add SWD_SEQ and SWD_TRANSACT commands to > jtag_command_type. > And add the corresponding struct in jtag_command_container. > Add swd_add_sequence, swd_add_transact_out, swd_add_transact_in. > And corresponding implementations in driver.c. > Implement the SWD codes in adi_v5_swd.c, and fix ahbap_debugport_init. I would recommend to put all this stuff into dedicated versaloon inferface driver and do not put any solution dependent code into arm_adi_v5 as this is neither part of the adi/target, nor swd transport itself... this would also allow designers to handle operations just as they like/need :-) > What's more, we'll need a command to set trn of SWD. This is done by the interface function bridge that use only transfer and bitbang generic calls. Please take a look at kt-link-swd.cfg a
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Another problem: Should we create script files for targets which support SWD, remove jtag commands? For example, create stm32f1_jtag.cfg and stm32f1_swd.jtag instead of stm32f1.cfg. If "transport select swd" is called before processing target scripts, get_current_target in swd_init will fail. If "transport select swd" is called after processing target scripts, all jtag commands in target scripts will fail. simonqian.openocd From: simonqian.openocd Date: 2012-03-19 21:17 To: Tomek CEDRO CC: openocd-devel; Peter Stuge Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent I attached the patch for mem_ap_read_buf_swd, which looks like Tomek's patch. But the code it just same as JTAG ones. I'll later try implementing a swd_driver structure for Versaloon SWD driver. To Tomek: Do you have any supplement for swd_driver structure? I hope this job could be finished before 24th April, before which I can have enough time. simonqian.openocd From: simonqian.openocd Date: 2012-03-17 20:22 To: Tomek CEDRO CC: openocd-devel; Peter Stuge Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent Yes, these functions are in dap_ops structure. To implement SWD, nothing more than a dap_ops structure and a transport structure will be necessary. So, you mean use dap_ops struct as swd driver struct? A interface which supports SWD, will provide a dap_ops sturcture for swd operations? It's also OK for me, I can even write these functions in versaloon hardware. If we could define a common API for SWD, I can do the test ASAP. I found a swd_driver struct in swd.h, which seems much simpler. But I haven't tried using this driver. The driver has only 3 main APIs: int (*init)(uint8_t trn); int (*read_reg)(uint8_t cmd, uint32_t *value); int (*write_reg)(uint8_t cmd, uint32_t value); And current swd_dap_ops in adi_v5_swd.c simply calls these functions. simonqian.openocd From: Tomek CEDRO Date: 2012-03-17 18:15 To: simonqian.openocd CC: openocd-devel; Peter Stuge Subject: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent On Mar 17, 2012 8:40 AM, "simonqian.openocd" wrote: > Next will be adding the SWD drivers. In order to have generic driver for transport layer I have introduced TRANSFER and BITBANG methods to the interface structure. transfer can send in and out bitstream from the array of chars, array of chars is provided by transport-interface bridge, so the same function can be used in transport for different drivers. BITBANG is used to control interface port state, it can read and write to the port, specificaly driver then RnW/TRN buffers. These two functions are the minimal set of functions to implement any transport possible :-) > I recommend to user the current JTAG queue functions. Nope, that would create dependecy of transport on the openocd queue. OpenOCD queue should be left for internal use only (also jtag queue should be moved out from there into jtag transport). TRANSPORT is here to translate target commands (ie. mem-ap read) into interface sequences (ie. bitstream for generic drivers such as ft2232 or gpio and commands for inteligent drivers such as versaloon). LibSWD has its own internal queue and can handle DP/AP read/write and pass the result to the drivers. The design idea was to have swd working even on the gpio or parallel port with two resistor (maybe some diode) interface :-) Versaloon as the intelligent driver has also its own queue in the interface, target would simply send commands to the interface and interface will handle the dp/ap read/write. Transport structure use function pointers for this - jtag has its own (or should), swd has its own - selecting transport simply switches the function set and calls transport_select function from the set... The transport functions are defined in transport.h and it goes something like: DAP_IDCODE DAP_ABORT DAP_FLUSH DP_READ DP_WRITE AP_READ AP_WRITE This is all what is necessary to talk to the ADI using SWD. LibSWD get commands and translates it into operations that can be used by any interface, lets call it swd_generic transport - it requires at least two interface functions: 1 to transfer bitstream in efficient way, 2 to set the buffers for TRN. Versaloon can handle the commands itself so it can use another transport that simply pass the dap operations to the interface, lets call it swd_dedicated transport - in this case the inferface needs only one function that would pass the dap operations into/from the dedicated driver. The mentioned queue mechanism should be implemented in this place, at best in the versaloon interface driver, because different drivers can have different needs for buffering/enqueing.. This is clean and elegant solution huh..? :-) > In my original SWD patch, I add SWD_SEQ and SWD_TRANSACT commands to > jtag_command_type. > And add the corresponding struct in jtag_command_container. > Add swd_add_sequence, swd_add_transact_out, swd_add_transact_in. >
Re: [OpenOCD-devel] What type of memory is referred to in "Error: address + size wrapped"?
I guess you are trying to access 0x as a 32-bit instruction or data, so the debugger will access 0xFFFE(0x & ~3). You should provide more debug message. simonqian.openocd From: Justin Drake Date: 2012-03-23 00:06 To: openocd-devel Subject: [OpenOCD-devel] What type of memory is referred to in "Error: address + size wrapped"? I am getting the following error on the OpenOCD terminal: Error: address + size wrapped(0xfffe, 0x0004) What address is referred to? What do the two addresses 0xfffe and 0x0004 correspond to? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
Again, I post the similar topic for SWD support. Before the SWD driver layer, there is only 2 fixes must be committed. The first is to make mem_ap_read_buf_u32 adaptor independent. The second is to add SWD support in ahbap_debugport_init. So, some others should look into this. I'll be on a 15-day holiday next Wendesday, so maybe I can't prepare for the patch. And actually, I don't know how to patch it. Or I can add the second patch to review first. simonqian.openocd-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
Hello, > The read and init operation is different in error handling between JTAG and > SWD. Are there any other differences? Yes, and init function should initialize selected adaptor instead of JTAG only. > INIT function requires something like 'check and clear dap errors' to become > transport independent. I have already created such function in libswd_dap.c > please take a look - the parameters are pointers to CTRLSTAT and ABORT > registers, the first will contain CTRLSTAT valuue upon return and ABORT > contains mask which will tell what errors flags can be cleared (all of them > if value is 0x). It would only require to do the same for JTAG and the > aproppriate function wrapper :-) are there any other changes you want to do > in this part? No, all this is necessary. Again, no care how it is implemented, but it must be implemented in some way for SWD. > MEMAP_READ can be transport independent if the retry and error handling is > done within transport function, which is already done with libswd_dap.c. This > is already done by your Versaloon driver by the hardware. The only thing > would be to change JTAG part, but the wrapper is okay for me at the moment > because it works and it does not change existing JTAG code at all... But if JTAG memap_read is transport independent, maybe there will be a performance problem. I'm not sure how to process this patch. simonqian.openocd From: Tomek CEDRO Date: 2012-04-17 03:45 To: simonqian.openocd CC: openocd-devel Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent Hello Simon :-) The read and init operation is different in error handling between JTAG and SWD. Are there any other differences? INIT function requires something like 'check and clear dap errors' to become transport independent. I have already created such function in libswd_dap.c please take a look - the parameters are pointers to CTRLSTAT and ABORT registers, the first will contain CTRLSTAT valuue upon return and ABORT contains mask which will tell what errors flags can be cleared (all of them if value is 0x). It would only require to do the same for JTAG and the aproppriate function wrapper :-) are there any other changes you want to do in this part? MEMAP_READ can be transport independent if the retry and error handling is done within transport function, which is already done with libswd_dap.c. This is already done by your Versaloon driver by the hardware. The only thing would be to change JTAG part, but the wrapper is okay for me at the moment because it works and it does not change existing JTAG code at all... Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Apr 16, 2012 7:54 PM, "simonqian.openocd" wrote: Again, I post the similar topic for SWD support. Before the SWD driver layer, there is only 2 fixes must be committed. The first is to make mem_ap_read_buf_u32 adaptor independent. The second is to add SWD support in ahbap_debugport_init. So, some others should look into this. I'll be on a 15-day holiday next Wendesday, so maybe I can't prepare for the patch. And actually, I don't know how to patch it. Or I can add the second patch to review first. simonqian.openocd -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
>> > The read and init operation is different in error handling between JTAG >> > and SWD. Are there any other differences? >> >> Yes, and init function should initialize selected adaptor instead of JTAG >> only. >Adapter is another layer, an interface. Target functions should not touch >anything except target. The transport has its own routines: SELECT and INIT, >they are part of the transport dap_ops, maybe you are regarding to them? :-) OK, it can be implemented when SELECT and INIT transport. It's a better solution. >> No, all this is necessary. Again, no care how it is implemented, but it must >> be implemented in some way for SWD. >Then it can be another function in dap_ops, a smarter replacement for current >ABORT..? Yes, I prefer this. But OpenOCD maintainer should look into this and do the decision. >> But if JTAG memap_read is transport independent, maybe there will be a >> performance problem. >> I'm not sure how to process this patch. >This can be true as the impelementation of this part can take retry and error >flags handling into account whereas other functions dont anf this could >produce a slowdown. Will take a look at this when swd is finished, right now >it it working and noone complains so I would not touch this part:-) No, you mis-understanding, I mean that remove adi_jtag_dp_scan in mem_ap_read_buf_u32, so that this function can be transport independent. And again, OpenOCD maintainer should look into this and do the decision. simonqian.openocd From: Tomek CEDRO Date: 2012-04-17 14:25 To: simonqian.openocd CC: openocd-devel Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent On Apr 17, 2012 4:17 AM, "simonqian.openocd" wrote: > > Hello, > > > The read and init operation is different in error handling between JTAG and > > SWD. Are there any other differences? > > Yes, and init function should initialize selected adaptor instead of JTAG > only. Adapter is another layer, an interface. Target functions should not touch anything except target. The transport has its own routines: SELECT and INIT, they are part of the transport dap_ops, maybe you are regarding to them? :-) > No, all this is necessary. Again, no care how it is implemented, but it must > be implemented in some way for SWD. Then it can be another function in dap_ops, a smarter replacement for current ABORT..? > But if JTAG memap_read is transport independent, maybe there will be a > performance problem. > I'm not sure how to process this patch. This can be true as the impelementation of this part can take retry and error flags handling into account whereas other functions dont anf this could produce a slowdown. Will take a look at this when swd is finished, right now it it working and noone complains so I would not touch this part:-) Best regards, Tomek-- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
Here is my patch: http://openocd.zylin.com/#/c/565/. It's similar to Tomek's code, which implements mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. I'm not sure whether we can implement a single mem_ap_read_buf_u32 which supports both JTAG and SWD. If it's possible, I prefer to a single mem_ap_read_buf_u32, because codes in arm_adi_v5.c should be transport independent. simonqian.openocd From: Peter Stuge Date: 2012-04-17 14:57 To: openocd-devel Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent simonqian.openocd wrote: > >> No, all this is necessary. Again, no care how it is implemented, > >> but it must be implemented in some way for SWD. > >Then it can be another function in dap_ops, a smarter replacement > >for current ABORT..? > Yes, I prefer this. But OpenOCD maintainer should look into this > and do the decision. If you and Tomek are in agreement then I will immediately work on any patches you propose. Send me code any way you can. The best would be via gerrit, but other methods are also good. If a patch is already in gerrit then please let me know and I will look at it. > >> But if JTAG memap_read is transport independent, maybe there > >> will be a performance problem. I'm not sure how to process this > >> patch. I think the first priority is to make it work, performance is only the second objective. > >This can be true as the impelementation of this part can take > >retry and error flags handling into account whereas other > >functions dont anf this could produce a slowdown. Will take a look > >at this when swd is finished, right now it it working and noone > >complains so I would not touch this part:-) > > No, you mis-understanding, I mean that remove adi_jtag_dp_scan in > mem_ap_read_buf_u32, so that this function can be transport independent. > And again, OpenOCD maintainer should look into this and do the decision. I am very sorry for not having a better understand of this already - what exactly is the needed decision? Kind regards //Peter -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
I have implemented the mem_ap_read_buf_u32 function which is adaptor
independent.
But I added a extra parameter to dap_queue_dp_read and dap_queue_ap_read,
because of posted operations when read.
Actually, there is difference between JTAG and SWD in RDBUFF behaviour, please
refer to IHI0031A_ARM_debug_interface_v5 file, section 6.2.5 and some other
related sections. So there is always problem when implementing a unique
dap_queue_dp_read for both JTAG and SWD.
Below is dap_queue_dp_read:
static inline int dap_queue_dp_read(struct adiv5_dap *dap,
unsigned reg, uint32_t *data, uint8_t post_process)
{
assert(dap->ops != NULL);
return dap->ops->queue_dp_read(dap, reg, data, post_process);
}
I add post_process to indicate whether the driver should process posted
operations when read.
Of course, post_process parameter is also added to queue_ap_read and
queue_dp_read in dap_ops structure.
And I tested it OK on JTAG on stm32 with no performance lost.
I'll leave tomorrow to Europe for my vacation, so I'll test SWD adaptor when
back after 2 weeks.
I commit the code to review today, and people can post comments.
simonqian.openocd
From: Peter Stuge
Date: 2012-04-17 16:39
To: openocd-devel
Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Tomek CEDRO wrote:
> Things that I have proposed are already implemented and can be
> verified at my local fork at http://repo.or.cz/w/openocd/libswd.git
> :-)
>
> I want to make rebase but I have filtered connection problems abroad
> and I will do that after my return next week :-)
Please focus on Simon's patch in Gerrit, do you see some way that it
can be made more meaningful for the libswd effort?
It does not have to be an exact fit, but it should be in the right
direction. There can and should be further patches after we get this
patch from Simon's included.
Thanks!
//Peter
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
Yes, your functions are OK.
But in my implementation, there are no mem_ap_read_buf_u32_jtag and
mem_ap_read_buf_u32_swd, because the patch with 2 mem_ap_read_buf_u32 functions
is not allowed.
So I have to implement a single mem_ap_read_buf_u32, which is already in the
review list.
But it's not simple because of the differences between JTAG and SWD.
You can try to use dap_queue_dp_read and dap_queue_ap_read instead of
adi_jtag_dp_scan, to see whether it works for JTAG.
But for SWD, it's OK, because of the difference when access RDBUFF on JTAG and
SWD.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-04-24 17:36
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Hello Simon :-) What is the exact function of the posprocess and why it is not
possible to work without that parameter? My code does not change the API and it
works both for JTAG and SWD. Why is wrapper bad? It has to be implemented
anyway..?
Have a nice trip to Europe! Which country(ies) will you visit? :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Apr 24, 2012 11:23 AM, "simonqian.openocd"
wrote:
I have implemented the mem_ap_read_buf_u32 function which is adaptor
independent.
But I added a extra parameter to dap_queue_dp_read and dap_queue_ap_read,
because of posted operations when read.
Actually, there is difference between JTAG and SWD in RDBUFF behaviour, please
refer to IHI0031A_ARM_debug_interface_v5 file, section 6.2.5 and some other
related sections. So there is always problem when implementing a unique
dap_queue_dp_read for both JTAG and SWD.
Below is dap_queue_dp_read:
static inline int dap_queue_dp_read(struct adiv5_dap *dap,
unsigned reg, uint32_t *data, uint8_t post_process)
{
assert(dap->ops != NULL);
return dap->ops->queue_dp_read(dap, reg, data, post_process);
}
I add post_process to indicate whether the driver should process posted
operations when read.
Of course, post_process parameter is also added to queue_ap_read and
queue_dp_read in dap_ops structure.
And I tested it OK on JTAG on stm32 with no performance lost.
I'll leave tomorrow to Europe for my vacation, so I'll test SWD adaptor when
back after 2 weeks.
I commit the code to review today, and people can post comments.
simonqian.openocd
From: Peter Stuge
Date: 2012-04-17 16:39
To: openocd-devel
Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Tomek CEDRO wrote:
> Things that I have proposed are already implemented and can be
> verified at my local fork at http://repo.or.cz/w/openocd/libswd.git
> :-)
>
> I want to make rebase but I have filtered connection problems abroad
> and I will do that after my return next week :-)
Please focus on Simon's patch in Gerrit, do you see some way that it
can be made more meaningful for the libswd effort?
It does not have to be an exact fit, but it should be in the right
direction. There can and should be further patches after we get this
patch from Simon's included.
Thanks!
//Peter
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
Maybe there is some other way to omit this parameter, I'll be happy to use it
if it is possible.
I just pointed out the problem why it doesn't work if we use dap_queue_ap_read
and dap_queue_dp_read instead of adi_jtag_dp_scan.
BTW, I'll visit Switzerland and France, hope there will be free wifi in my
hotel.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-04-24 17:36
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Hello Simon :-) What is the exact function of the posprocess and why it is not
possible to work without that parameter? My code does not change the API and it
works both for JTAG and SWD. Why is wrapper bad? It has to be implemented
anyway..?
Have a nice trip to Europe! Which country(ies) will you visit? :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Apr 24, 2012 11:23 AM, "simonqian.openocd"
wrote:
I have implemented the mem_ap_read_buf_u32 function which is adaptor
independent.
But I added a extra parameter to dap_queue_dp_read and dap_queue_ap_read,
because of posted operations when read.
Actually, there is difference between JTAG and SWD in RDBUFF behaviour, please
refer to IHI0031A_ARM_debug_interface_v5 file, section 6.2.5 and some other
related sections. So there is always problem when implementing a unique
dap_queue_dp_read for both JTAG and SWD.
Below is dap_queue_dp_read:
static inline int dap_queue_dp_read(struct adiv5_dap *dap,
unsigned reg, uint32_t *data, uint8_t post_process)
{
assert(dap->ops != NULL);
return dap->ops->queue_dp_read(dap, reg, data, post_process);
}
I add post_process to indicate whether the driver should process posted
operations when read.
Of course, post_process parameter is also added to queue_ap_read and
queue_dp_read in dap_ops structure.
And I tested it OK on JTAG on stm32 with no performance lost.
I'll leave tomorrow to Europe for my vacation, so I'll test SWD adaptor when
back after 2 weeks.
I commit the code to review today, and people can post comments.
simonqian.openocd
From: Peter Stuge
Date: 2012-04-17 16:39
To: openocd-devel
Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Tomek CEDRO wrote:
> Things that I have proposed are already implemented and can be
> verified at my local fork at http://repo.or.cz/w/openocd/libswd.git
> :-)
>
> I want to make rebase but I have filtered connection problems abroad
> and I will do that after my return next week :-)
Please focus on Simon's patch in Gerrit, do you see some way that it
can be made more meaningful for the libswd effort?
It does not have to be an exact fit, but it should be in the right
direction. There can and should be further patches after we get this
patch from Simon's included.
Thanks!
//Peter
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD release cycle
>>> http://sourceforge.net/projects/openocd/files/openocd/ >>> Just wondering if there is any roadmap to 0.6.0 release. >>> Is libswd integration a must for 0.6.0? >> >> We don't plan features for releases, we release what's committed to >> the master branch at the time of release. >> >> Whether or not a feature makes it for a release is purely a matter of >> whether the community was able to get it to master branch or not. >That is good to know. I hope SWD support can be ready in 0.6.0 releases, there is some progress, and it's "almost there" to make openocd ready for committing SWD drivers. simonqian.openocd-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
Hi,
I'm back from Europe.
About ADIv5 APIs in current openocd, I'm considering add a set of APIs, which
can do AP and DP access with no post process.
For example:
static int adi_jtag_drv_dp_read_u32(struct adiv5_dap *dap,
uint8_t reg_addr, uint32_t outvalue, uint32_t *invalue, uint8_t *ack)
{
return adi_jtag_dp_scan_u32(dap, JTAG_DP_APACC, reg_addr, DPAP_READ,
outvalue, invalue, ack);
}
And move current ADIv5 APIs to arm_adi_v5.c because they are adaptor
independent.
If looking into my latest adi_v5_swd.c, they are almost the same as in
adi_v5_jtag.c.
I have attached a diff file for adi_v5_swd.c and adi_v5_jtag.c.
It will also greatly simplify the SWD driver implementation, but again if using
bit-bang operation, the speed is limited.
Maybe I can also implement a bit-bang driver for SWD, but I will need some help.
BTW:
I've updated the SWD speed using my SWD patch, it can be the same speed as JTAG:
Info : device id = 0x10036414
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 0 with 4 bytes
Warn : no flash bank found for address 804
wrote 262144 bytes from file Versaloon.hex in 7.988457s (32.046 KiB/s)
dumped 32768 bytes in 0.471027s (67.937 KiB/s)
simonqian.openocd
From: simonqian.openocd
Date: 2012-04-24 17:50
To: Tomek CEDRO
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Maybe there is some other way to omit this parameter, I'll be happy to use it
if it is possible.
I just pointed out the problem why it doesn't work if we use dap_queue_ap_read
and dap_queue_dp_read instead of adi_jtag_dp_scan.
BTW, I'll visit Switzerland and France, hope there will be free wifi in my
hotel.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-04-24 17:36
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Hello Simon :-) What is the exact function of the posprocess and why it is not
possible to work without that parameter? My code does not change the API and it
works both for JTAG and SWD. Why is wrapper bad? It has to be implemented
anyway..?
Have a nice trip to Europe! Which country(ies) will you visit? :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Apr 24, 2012 11:23 AM, "simonqian.openocd"
wrote:
I have implemented the mem_ap_read_buf_u32 function which is adaptor
independent.
But I added a extra parameter to dap_queue_dp_read and dap_queue_ap_read,
because of posted operations when read.
Actually, there is difference between JTAG and SWD in RDBUFF behaviour, please
refer to IHI0031A_ARM_debug_interface_v5 file, section 6.2.5 and some other
related sections. So there is always problem when implementing a unique
dap_queue_dp_read for both JTAG and SWD.
Below is dap_queue_dp_read:
static inline int dap_queue_dp_read(struct adiv5_dap *dap,
unsigned reg, uint32_t *data, uint8_t post_process)
{
assert(dap->ops != NULL);
return dap->ops->queue_dp_read(dap, reg, data, post_process);
}
I add post_process to indicate whether the driver should process posted
operations when read.
Of course, post_process parameter is also added to queue_ap_read and
queue_dp_read in dap_ops structure.
And I tested it OK on JTAG on stm32 with no performance lost.
I'll leave tomorrow to Europe for my vacation, so I'll test SWD adaptor when
back after 2 weeks.
I commit the code to review today, and people can post comments.
simonqian.openocd
From: Peter Stuge
Date: 2012-04-17 16:39
To: openocd-devel
Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Tomek CEDRO wrote:
> Things that I have proposed are already implemented and can be
> verified at my local fork at http://repo.or.cz/w/openocd/libswd.git
> :-)
>
> I want to make rebase but I have filtered connection problems abroad
> and I will do that after my return next week :-)
Please focus on Simon's patch in Gerrit, do you see some way that it
can be made more meaningful for the libswd effort?
It does not have to be an exact fit, but it should be in the right
direction. There can and should be further patches after we get this
patch from Simon's included.
Thanks!
//Peter
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
adi_v5_xxx.diff
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussio
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
> One thing that Versaloon and other MCU based HW > has advantage is that the MCU does quite some time > critical work. On the contrary, FTDI based HW will be > at the mercy of the host since there are no intelligence > within the HW. > http://openocd.sourceforge.net/doc/doxygen/html/ft2232_8c.html > + > FT2232 based JTAG adapters are "dumb" not "smart", because > most JTAG request/response interactions involve round trips > over the USB link. A "smart" JTAG adapter has intelligence > close to the scan chain, so it can for example poll quickly for a > status change (usually taking on the order of microseconds not > milliseconds) before beginning a queued transaction which > require the previous one to have completed. > + It's true for other adapters for example SWD, but it's not true for generic JTAG. There is no high level interface for JTAG, so all the JTAG dongle does in the same way in openocd. Of course, MCU based adapters can be smart, but after they implement a generic ADIv5 layer. And libSWD is not libSWD only, but libADIv5. Before that, they are as "dumb" as FT2232 based JTAG dongles. > See the above, the USB delay does play a big part to > reduce the high speed USB advantage of FTx232H (125us > USB microframe time). I think the way to evaluate the USB delay will be below. It depends on the rate between the time used to do the transaction and the time used to do the JTAG operation. If the JTAG time is much longer than the transaction time, there will not be significant performance descend. For current openocd code, a memory access can be as large as 4K bytes for CM3 and 1K bytes for CM0. So for large memory accesses, every 4KB will has a "endcheck" which will poll the result of the access. So it's not a great payload. But for small memory access eg 32-bit access, it another story. simonqian.openocd-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor independent
> Yes, the USB is the critical bottleneck not only for SWD but also JTAg which > I had occasion to check in practice recently. Please note that LibSWD can > easily become a part of the smart adapter firmware if necessary (it would be > nice to check its functionalities firsr however). It's more critical for SWD because each SWD transaction should be polled in bit-band mode. simonqian.openocd-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD-BOX
I just read this thread. Actually I'm considering implement a device with embedded GDB server. Hope I can have enough time for this. Below is my solution, 480M USB: MCU with 480M USB, RNDIS on USB, so it will appear on OSs as a NIC. Implement a GDB server connecting to the NIC. So the hardware will be as simple as Versaloon, but need more flash an ram. And I don't plan to use linux or uclinux. simonqian.openocd From: Xiaofan Chen Date: 2012-05-22 16:25 To: Tomek CEDRO CC: openocd-devel Subject: Re: [OpenOCD-devel] OpenOCD-BOX On Tue, May 22, 2012 at 4:23 PM, Xiaofan Chen wrote: > On Tue, May 22, 2012 at 4:45 AM, Tomek CEDRO wrote: >> Hello :-) >> >> Simple USB JTAG adapters are not fast enough for operational analysis >> of devices. The commercial ones are fast but limited in >> functionalities and not extensible. The perfect solution would be to >> have/create OpenOCD-BOX that would have fast and extensive GPIO with >> buffers, maybe FPGA based, so it could act as JTAG/SWD/SPI/... >> interface with Telnet/USB/Serial access for user commands. Having this >> solution would also be a good reason to develop and make OpenOCD more >> functional maybe some good way for project funding to get boards and >> other stuff for developers? :-) >> >> Anyone know / want to design / has this solution / product? :-) > > So far the replies are mostly geared toward embedded Linux solution, > which may be more powerful and yet with lower cost. > > I do not know much with embedded Linux but I think simpler > MCU based open solution can already perform quite well, eg, > Simon's Versaloon. > > Adding a FPGA on top of MCU based solution may be easier > than the embedded Linux solution and the latency may actually > be better than embedded Linux. > The other thing is that I doubt the commercial viability of such project. It can be a fun project but in the end without the support of a commercial toolchain (eg: IAR, Keil, etc), I am not so sure how successful this will be. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD-BOX
> Not so many choices for the MCU, but at least there is SAM3U and > hopefully sometime soon the LPC1820 goes into production. Yes, the MCU I will use is SAM3U. > DHCP server in the MCU is important for usability. I think the CDC > Ethernet interface class is quite widely compatible and is also a > good choice for good usability. A static IP address can be used, and add an entry to the route table will do it. Of course, DHCP can be a plus, but there is possibility of conflict with current internet network. simonqian.openocd-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] JTAG through USB and TRACE
If you want to update STM32 firmware and CPLD, you can try Versaloon with USB ISP bootloader. usb_isp bootloader emulate a CDC-ACM device with COM ISP protocol of STM32, so you can use any stm32 ISP tool to update the firmware. And there is both stm32 com isp support and VSF support in vsprog. But vsf support in vsprog is less maintained than one in OpenOCD. simonqian.openocd From: Andrew Leech Date: 2012-07-04 07:35 To: openocd-devel Subject: Re: [OpenOCD-devel] JTAG through USB and TRACE On 4/07/12 3:01 AM, Vaclav Peroutka wrote: Hello all, for one my hobby project ( http://mz800ukp1.sourceforge.net/ ) I use STM32 and CPLD. My idea is to replace current MCU with F205 and use onchip USB to update firmware in both MCU and CPLD. Mode switching between CPLD SVF update, FW update and "user mode" will be done by jumpers. My idea is to emulate some well known interface already available by openocd. usb_blaster for CPLD maybe ? But for firmware selfupdate, I don't have any idea what can be usable. Or is it better not to rely on OpenOCD and write some PC application from the scratch communicating through CDC class ? Another idea - is there any free means for communication with ETM on Cortex M3 ? I tried to find one but no success. Maybe I ask wrong questions to Google. Thank you in advance, Vaclav Hi, I do a very similar thing on a current product, which is based on an lpc3131 (arm9) and an actel fpga. I actually ended up using JAM Stapl Player (altera/actel) on the pc end to do the fpga programming, and wrote a program for my lpc to emulate the serial programmer it supports. I initially wrote it as usb cdc but later ported it and stapl_player to run on hid instead to avoid driver/port hassles. It works quite well, but takes 3-5minutes to program which I'd really like to improve as opposed to my ft2232 based dongle programming it in about 1.5minutes. To make this possible I set up my pcb layout such that some gpio on the arm can take over the jtag lines on the fpga, it doesn't have any other serial update methods, just jtag. At the time I didn't see any openocd supported programmer with a usb interface I thought I could easily replicate, hence went with the standalone tool. Looking at it now though, opendous-jtag looks like it'd be pretty straightforward to replicate. I don't know whether it'd be particularly quick or not though. I use the lpc's built in usb dfu bootloader mode to load the programmer firmware, then run stapl player on computer to load the stapl file. You should look at versaloon though if you're planning on using an STM32, that's what it's written for. If you pin out your pcb correctly you could probably use it with minimal or no modification. As far as the arm's concerned, my programs stored in external flash chip, so I just had to write a loader that could write my rom file to that flash. As part of my build procedure I actually convert my firmware.rom into a *.o object file and link it to a predetermined location in my arm loader program which gives my a single final file I load over the usb dfu. The loader program starts up, verifies the firmware.rom at the known memory buffer location, then flashes it to the external flash chip. It's really quite neat and straightforward. Again, there's probably a simpler way for you too, look up ST UM0412 "Getting started with DfuSe USB device firmware upgrade". Looks like ST have it nicely built in for you. Andrew-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Versaloon support
What's the problem about the Versaloon hardware? simonqian.openocd From: Akos Vandra Date: 2012-07-06 14:10 To: Spencer Oliver CC: openocd-devel Subject: Re: [OpenOCD-devel] Versaloon support Yeah, that's the thing that confused me. I had problems with the hardware as well, and didn't know where to search for the fault. Regards, Ákos Vandra On 5 July 2012 10:56, Spencer Oliver wrote: > On 5 July 2012 04:50, Peter Stuge wrote: >> >> I think it would be good to change the name to --enable-versaloon >> however, to make it more obvious what it is for. >> > > +1 from me > > Spen > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] openocd+libswd call for testing work in progress...
For SWD, some more wise device is necessary to speed up. I'll try to add my code into the latest libswd when ready. BTW, FT2232H could be faster, it uses 480M USB, with 125us micro frame. As to OpenOCD-Box, I'm considering to use Android devices, it's not expensive if using solutions from Chinese provider, the cost will be about $40 for a quard-core A9 solution with outer case. If using android later than 3.0, I can simply implement a USB connection to my Versaloon, and implement an APK to control the openocd in linux below. simonqian.openocd From: CeDeROM Date: 2012-11-28 18:50 To: Freddie Chopin CC: openocd-devel Subject: Re: [OpenOCD-devel] openocd+libswd call for testing work in progress... On Wed, Nov 28, 2012 at 10:22 AM, Freddie Chopin wrote: > With connected interface (JTAG-lock-pick Tiny 2) and connected target (STM32 > HD VL via SWD) I can do some basic operations, which are really slow, but > seem to work The speed is limited mainly by the USB bottleneck, it should not be an issue on GPIO based adapters, this is why I have asked some time ago about OpneOCD-BOX or the other device that runs openocd inside and have direct gpio access provided... I have bought Carambolla, maybe that will work, maybe Zylin is good candidate, time will show :-) Each transaction in SWD consists of 3 phases, and there can be as much as 3 direction changes in each transaction, which means 3 (or more) flushes to the USB device, so there real limitation here is the USB latency. This can change when using libusb-1.0 and async access. Some more optimizations are possible also, but lets make things work first :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel-- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] openocd+libswd call for testing work in progress...
Hello, OK, I think I will be able to port Versaloon into the new interface organization. > ps/2: Where did you see A9xCPU for $40? :-) Not A9xCPU for $40, but a total solution for $40, of course it's the price for large quantity order. It's not open to the public now, I'll get contact with them these days. On taobao.com (which is something like ebay in China), you can even find some miniPC (android based console without screen, but has hdmi) are sold at $30 - $40. I have ported Versaloon driver to Android 4.0+ with Usb OTG feature, aims at some industry solutions, which will be a great cost down to original solutions. Users can simply develop applications on Android with my library to communicate with some specified peripherals. simonqian.openocd From: CeDeROM Date: 2012-11-30 03:38 To: simonqian.openocd CC: openocd-devel Subject: Re: Re: [OpenOCD-devel] openocd+libswd call for testing work in progress... On Thu, Nov 29, 2012 at 6:55 AM, simonqian.openocd wrote: > For SWD, some more wise device is necessary to speed up. > I'll try to add my code into the latest libswd when ready. Hello Simon :-) I have made some preparations for the OpenOCD to accept different solutions for transport implementation - its called Interface Feature. When you do a Setup of a Transport, a feature will be searched on a currently selected Interface. You should provide your own feature definition for a Versaloon (this was previously named dap_ops and you probably already have it working). If no SWD feature is provided by an Interface, by default LibSWD is tried. If your Interface provide "transfer" and "bitbang" methods, LibSWD will work on that too :-) In this new Interface organization all interfaces should provide minimal generic "transfer" and "bitbang" functions, and they can provide their own Features for additional tasks. If the feature has no dedicated implementation for that given interface, a generic one will be used based on "transfer" and "bitbang" methods and some generic feature. Best regards :-) Tomek ps/2: Where did you see A9xCPU for $40? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info-- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenSDA?
Hi, I have added some kinetis support code, but it's not tested. I currently don't have the hardware and time to complete kinetis support. I'll check the compile error. simonqian.openocd From: Alan Carvalho de Assis Date: 2013-03-19 05:20 To: simonqian.openocd CC: spen; openocd-devel Subject: Re: Re: [OpenOCD-devel] OpenSDA? Hi Simon, On 3/18/13, simonqian.openocd wrote: > I see this too, it seems that he want to add a CDC port onto stlink. > But it's not necessary to hack the firmware, it's much more simpler to > develop a new one compatible to stlink. > I have done this, and also add a CDC port, and even intergrate versaloon. > But I'm not sure whether it can support kinetis, because CM0+ kinetis > implement > a MDM-AP, is it supported by OpenOCD? > I saw your vsprog has support to Kinetis KL25Z used on Freedom board, then I compiled it and fixed some minor issues: interfaces/versaloon/versaloon.c:181:2: error: incompatible implicit declaration of built-in function �free?[-Werror] Just add "#include " to interfaces/versaloon/versaloon.c Then it goes on, but when it was almost there it failed to generate final binary: mv -f .deps/vsprog-app_log.Tpo .deps/vsprog-app_log.Po gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wno-unused-parameter -Wno-missing-field-initializers -Werror -Wextra -Wbad-function-cast -Wcast-align -Wredundant-decls -I/usr/include/libxml2 -o vsprog vsprog-vsprog.o vsprog-app_log.o ../src/scripts/libscripts.a ../src/programmer/libprog.a ../src/target/libtgt.a ../src/tools/libtool.a ../src/driver/libdrv.a ../vsf/libvsf.a -lusb -L/usr/lib -lxml2 ../src/programmer/libprog.a(versaloon.o):(.data+0x8): undefined reference to `versaloon_usb_comm' then I modified programmer/Makefile.am to include the source where this reference is created: libprog_a_SOURCES = \ programmer.c \ interfaces/interfaces.c \ interfaces/versaloon/versaloon.c \ +interfaces/versaloon/versaloon_libusb.c \ $(vsf_usbtoxxx_srcdir)/usbtoxxx.c \ $(vsf_usbtoxxx_srcdir)/usbtogpio.c \ $(vsf_usbtoxxx_srcdir)/usbtospi.c \ I reconfigured and compiled again, now the binary is created, but it is returning seg-fault when trying to communicate with FRDM board. Did you get it working with FRDM board? I'm using Ubuntu 12.10 32bits : $ uname -a Linux bob 3.6.11-vanillaice #1 SMP Tue Feb 5 16:57:12 BRST 2013 i686 i686 i686 GNU/Linux $ cat /etc/issue.net Ubuntu 12.10 Sorry ask this questions at openocd mail list, but I don't have access to versaloon at yahoo groups yet (Your membership is awaiting approval by the group owner). Best Regards, Alan-- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Is SWD now available in OpenOCD?
Hi, all It's almost 5 years after my first implementation in OpenoCD of SWD support for Versaloon. This support is not maintained for a long time, because I'm too busy with my job. These days, I received a request from an vendor of Cortex ARM to implement a SWD debugger. So I go back with the SWD code, and found OpenOCD has fixed some problem, arm_adi_v5.c is not dependent on JTAG now. I plan to add the SWD support of Versaloon in OpenOCD way. The first problem, is that the target scripts are dependent on JTAG layer. Is there any STM32F1X scripts which can be used in SWD mode, I mean without JTAG-specific commands? simonqian.openocd-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
