[Openocd-development] Patch to Fix J-link Debugger Communication Failures
Hello Øyvind, for me it looks that the J-Link is reseted. The manual give the information that this command activates TRST and release it after 2ms. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] packaging OpenOCD for 0.2.0
Hello Øyvind Michael Fischer has maintained a really neat website with lots of Windows binaries. Why should we dilute his efforts? You can distribute Windows binaries on berlios. I will link to it if available. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Can someone check this on windows too?
Hello List, I want to test the performance like Dominic had done before: https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html But here I use r2348 with libftdi and ftd2xx. dump_image without the fast memory access was working, but if I enable the fast memory access (arm7_9 fast_memory_access enable) I got some error messages like: couldn't write MPSSE command to FT2232 With libftdi and FTD2XX, the same result. I could not compile r2405, even not with the patch from Freddie. The problem with the patch is, that the cygwin patch program will not accept the patch itself. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Question about the driver install structure for libftdi
Hello List, from Freddie I know that a mix mode installer is working. Here libftdi is used for the JTAG part of the FT2232 chip, and the FTD2XX driver is used for the COM port of the chip. Now I can confirm that the COM port of the Turtelizer is working. The installation is a little strange, because the user must point to two different folders. -driver |-ftdilib |-non-gpl |-turtelizer For the JTAG port to ftdilib and for the COM port to turtelizer under non-gpl. In the moment I do not know if this is intuitive. Here we can use one ftdilib file for all of the devices, but I want to prefer the following structure: -driver |-turtelizer |-jtag |-com |-jtagkey |-jtag and so on. This should be more intuitive for the user. The disadvantage is that we need for each libftdi device his own libftdi inf file. But this is easier for the user, and the user should be the priority. @Zach, this is one point for the TODO list. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD and TCP/IP socket server (now I have understand GPL)
Hello List, as I understand it correct, everything can be used, even close software, if they do not use the same program space like the GPL application. Now I have understand while we can not use the wraper DLL! Second point, please correct me if I am wrong. To solve all the problem here with GPL and non GPL driver, it is allowed to use pipes, socket, or something other communication channels to use this non GPL driver. Because now the non GPL part use an other program space. In this case, I think the best solution, if we want to use the FTD2XX driver, is to use JTAG over TCP/IP like Øyvind has suggested before here: https://lists.berlios.de/pipermail/openocd-development/2009-June/008454.html Does it mean, we need a JTAG-Server which must be started before OpenCOD and where OpenOCD will communicate with? Could this be a solution which will be supported by all the parties here? If YES, I think we can close the GPL discussion, and go this way. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... I could not install my ftd2xx device here the normal way. I must use a composite version of the inf file. Regards, Michael -Ursprungliche Nachricht- Von: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de]im Auftrag von Freddie Chopin Gesendet: Sonntag, 21. Juni 2009 12:01 An: openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? Xiaofan Chen pisze: Using MinGW/Msys may be complicated. But it is not that difficult to use Cygwin. Installaing Cygwin it can be an issue for average Windows users though. So it's complicated anyway [; libusb-win32 device driver has the binary distribution. It is also very easy to build the svn version under Cygwin or MinGW/Msys. You need to know what to do with the created libraries - that's not a Windows kind of knowledge. I believe you do not need the hacked libusb0.sys file. I think you just need to create the INF file for the whole device in stead of individual device. But I need to get an FT2232x based JTAG tools to prove that. Or Gene Smith can test that. I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... 2) libftdi can be build under Cygwin pretty easily. Michael's SparkFun post mentioned that there would be errors. But with the latest libftdi 0.16 version, there are no errors any more. The most recent libftdi cannot be build under MSYS - the build fails, but the library is created. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hello Xiaofan, if the installer support more than FT2232 device, it must install all the driver this way. I think it is not a good idea, and the user should point to the directory where the driver exist. Like the normal way of installing driver. Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 12:27 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 6:23 PM, Michael Fischerfische...@t-online.de wrote: I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... I could not install my ftd2xx device here the normal way. I must use a composite version of the inf file. Try this. Gene Smith confirmed that it is working. https://lists.berlios.de/pipermail/openocd-development/2009-June/008220.html libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll jtagkey.inf -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. Best regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 12:46 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 6:38 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 6:33 PM, Michael Fischerfische...@t-online.de wrote: if the installer support more than FT2232 device, it must install all the driver this way. I think it is not a good idea, and the user should point to the directory where the driver exist. Like the normal way of installing driver. I see what you mean. Unfortunately this is sometimes the only way to install the libusb-win32 device driver based on my past experience. Windows will favor the existing WHQL based FTDI driver and refused to install the non-certified libusb-win32 driver. This is part of the complication of using libusb-win32 and libftdi under Windows. I agree with Freddie, FDT2xx is the nature choices for Windows user. The solution can be to build a binary package to automatically do this. libusb-win32 has an example of using NSIS. It is also possible to use other open source installers. http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/exa mples/ http://nsis.sourceforge.net/Main_Page -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Moreover, I do not have XP 64 or Vista 64 to test it. So I guess it is better not to distribute 64bit libusb-win32 driver. We do not want to distribute libusb, we want to distribute OpenOCD. And here libftdi is not working under 64 bit, is this correct? Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 13:55 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 7:15 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. That is great. I can help build the 64bit version of libusb-win32 svn version and send it to you later. You can also try to build it by yourself. 1) You can download the old DDK version here. http://www.microsoft.com/whdc/devtools/ddk/default.mspx 2) You can get latest WDK here. You need to use Microsoft Connect. http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx The moot point is that the 64bit libusb-win32 driver is only working under Windows XP 64 bit which does not have many users. It is not working under Vista 64 without some hacking. And I am not sure if OpenOCD built with MinGW can be used with the driver built with DDK/WDK (using compiler similar to Visual C++) for XP 64. I am not sure we can build OpenOCD with Visual C++ as of now. Moreover, I do not have XP 64 or Vista 64 to test it. So I guess it is better not to distribute 64bit libusb-win32 driver. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 Windows - summary of options
Hello List, No response, no windows user here which need FTD2XX support? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hi Xiaofan, many thanks for this hint. The 1.0.0.0 was not working here with OpenOCD. The libusb build based on 0.1.12.1 is working now. But this is the same version which the user can download from sourcefore. Perhaps someone should create a 0.1.12.2 for using with OpenOCD? Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 16:59 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. Oops, I forgot to mention that libusb-win32 1.0 SVN branch (named libusb1) is not working yet. So your version 1.0.0.0 is not ready yet. You should build the 0.1 branch (named libusb). There are two branches here: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/ The libusb branch is the stable branch and should work. DLL version:0.1.12.1 Driver version: 0.1.12.1 The libusb1 branch is the development branch and has WinUSB and HID backend along with the libusb-win32 device driver backend. But it is not working as far as I know. DLL version:1.0.0.0 Driver version: -1.-1.-1.-1 -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Did you try the released version of libusb-win32 which is 0.1.12.1. I think it should work as well. This was the version I used at the beginning. And here I need the hacked version from the page I send the info about the composite devices. Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 17:24 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 11:20 PM, Michael Fischerfische...@t-online.de wrote: many thanks for this hint. The 1.0.0.0 was not working here with OpenOCD. The libusb build based on 0.1.12.1 is working now. But this is the same version which the user can download from sourcefore. Perhaps someone should create a 0.1.12.2 for using with OpenOCD? The SVN version is slightly updated than the released 0.1.12.1 even though the version number is the same. Did you try the released version of libusb-win32 which is 0.1.12.1. I think it should work as well. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32
Hello Freddie, what is the md5sum from your libusb0.sys file under: \windows\system32\drivers The original file from the binary distribution libusb-win32-device-bin-0.1.12.1 is: 34d6730e198a5b0fce0790a6b4769ef2 *libusb0.sys Regards, Michael -Ursprungliche Nachricht- Von: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de]im Auftrag von Freddie Chopin Gesendet: Sonntag, 21. Juni 2009 17:26 An: openocd-development Betreff: Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32 Xiaofan Chen pisze: Have you tried this with all of the three JTAG tools? Nope [; I only have JTAGkey here, but the only difference visible to drivers is the VID/PID combination [; It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. It works for me - I can install the drivers and OpenOCD compiled with libftdi support is able to communicate with the core. Do you used the hacked libusb0.sys? Currently no, but I was using that a while ago, so I'm not sure whether it's not loaded in the RAM or something. I can upload openocd executable with libftdi support somewhere and post a download link for others to test. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hello List, But as it stands now, FTD2XX library is the nature choices for Windows users. So probably a more detailed document to build OpenOCD under Windows with FTD2XX is needed. The GPL issue can be highlighted and that the users can only use it as a private build and not distribute the binaries. The instruction can be found here, and use libftdi and libftd2xx: http://forum.sparkfun.com/viewtopic.php?t=11221 But the problem is that the normal user want to have a working solution and do not / can not build OpenOCD by itself. I think if libftdi will be used with the less performance as ftd2xx the new OpenOCD will not be used. Therefore the performance problem and the 64 bit problem must be solved to get an equivalent to the FTD2XX driver. Here I think the performance is the problem not the 64 bit first. Best regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Samstag, 20. Juni 2009 04:59 An: Zach Welch Cc: Harald Kipp; openocd-development@lists.berlios.de; Michael Fischer Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sat, Jun 20, 2009 at 9:04 AM, Zach Welchz...@superlucidity.net wrote: The community would be well advised to avoid these risks: use libftdi. I think it is not that difficult for people under Linux to use libftdi. But it is certainly not so easy to do that under Windows. Maybe a mini-howto will help for Windows user who want to libftdi. (for those who want to follow the GPL, accept the extra steps and potential performance penalties). But as it stands now, FTD2XX library is the nature choices for Windows users. So probably a more detailed document to build OpenOCD under Windows with FTD2XX is needed. The GPL issue can be highlighted and that the users can only use it as a private build and not distribute the binaries. P.S. At least one technical solution does exist that would allow FTD2XX to be used with OpenOCD, without loading libftd2xx inside OpenOCD. However, I think developing this feature will cost much more than simply fixing any bugs and deficiencies with libusb and libftdi, and fixing those libraries has more value for the broader open source community. For this reason, my technical solution deserves to be rejected as well. Just curious what is your technical solution and how difficult it is? It may be easier than fixing libusb+libftdi. You use the word 'simply. In reality it might be not that simple to fix libusb-win32+libftdi. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hello List, as I understand it correct, a private build with FTD2XX is correct! In this case we give the user the possibility to make a private build in a easy way. OpenOCD comes in a libftdi version, but at the same time there is a binary patch program available. Now the user can decide if they want to use the libfti or build his own ftd2xx version. Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Samstag, 20. Juni 2009 04:59 An: Zach Welch Cc: Harald Kipp; openocd-development@lists.berlios.de; Michael Fischer Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sat, Jun 20, 2009 at 9:04 AM, Zach Welchz...@superlucidity.net wrote: The community would be well advised to avoid these risks: use libftdi. I think it is not that difficult for people under Linux to use libftdi. But it is certainly not so easy to do that under Windows. Maybe a mini-howto will help for Windows user who want to libftdi. (for those who want to follow the GPL, accept the extra steps and potential performance penalties). But as it stands now, FTD2XX library is the nature choices for Windows users. So probably a more detailed document to build OpenOCD under Windows with FTD2XX is needed. The GPL issue can be highlighted and that the users can only use it as a private build and not distribute the binaries. P.S. At least one technical solution does exist that would allow FTD2XX to be used with OpenOCD, without loading libftd2xx inside OpenOCD. However, I think developing this feature will cost much more than simply fixing any bugs and deficiencies with libusb and libftdi, and fixing those libraries has more value for the broader open source community. For this reason, my technical solution deserves to be rejected as well. Just curious what is your technical solution and how difficult it is? It may be easier than fixing libusb+libftdi. You use the word 'simply. In reality it might be not that simple to fix libusb-win32+libftdi. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] I have removed my OpenOCD installer
Hello List, Thomas A. Moulton wrote: And to answer who could be sued? Well if a business takes a non-GPL complaint tool and redistributes it, then they could be at risk. So yes the developers are right to be GPL purists, it does matter! I have now removed my OpenOCD installer and will come back with a libftdi version and the ftd2xx-patch. If the user try to download OpenOCD they will get a note about the legal situation. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hello List, have you make a decision if the next official release will build on FTD2XX or on libftdi? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD + libftdi on Windows
Hello Freddie, upps, in case of performance I have tested here only download to RAM. And this looks like the same, 140 KB/sec. Btw, an old OpenOCD, r657, had a performance of about 165 KB/sec: http://www.yagarto.de/projects/jtagspeed/index.html Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problem with r2252 and mww
Hello List, I try to make a smoke test with the r2252. But in case of my SAM7SE512 I got an error: telnet: mww 0xf130 0x mww write memory word addr value [count] Runtime error, file command.c, line 469: openocd: Runtime error, file command.c, line 469: Runtime error, file command.c, line 469: It looks that it is not possible to write 0x. The same problem if I try to write 0x into the RAM: mww 0x20 0 mdw 0x20 0x0020: mww 0x20 0x mww write memory word addr value [count] Runtime error, file command.c, line 469: Tested with a JTAGkey and libftdi under WindowsXP. Best regards, MichaelDebug: 10 16 configuration.c:83 find_file(): found .\prj\jtagkey.cfg Debug: 12 16 command.c:68 script_debug(): command - telnet_port Debug: 13 16 command.c:77 script_debug(): telnet_port - argv[0]=ocd_telnet_port Debug: 14 16 command.c:77 script_debug(): telnet_port - argv[1]= Debug: 16 16 command.c:68 script_debug(): command - gdb_port Debug: 17 16 command.c:77 script_debug(): gdb_port - argv[0]=ocd_gdb_port Debug: 18 16 command.c:77 script_debug(): gdb_port - argv[1]= Debug: 20 16 command.c:68 script_debug(): command - tcl_port Debug: 21 16 command.c:77 script_debug(): tcl_port - argv[0]=ocd_tcl_port Debug: 22 16 command.c:77 script_debug(): tcl_port - argv[1]= Debug: 24 16 command.c:68 script_debug(): command - gdb_memory_map Debug: 25 16 command.c:77 script_debug(): gdb_memory_map - argv[0]=ocd_gdb_memory_map Debug: 26 16 command.c:77 script_debug(): gdb_memory_map - argv[1]=enable Debug: 28 16 command.c:68 script_debug(): command - gdb_flash_program Debug: 29 16 command.c:77 script_debug(): gdb_flash_program - argv[0]=ocd_gdb_flash_program Debug: 30 16 command.c:77 script_debug(): gdb_flash_program - argv[1]=enable Debug: 32 16 command.c:68 script_debug(): command - interface Debug: 33 16 command.c:77 script_debug(): interface - argv[0]=ocd_interface Debug: 34 16 command.c:77 script_debug(): interface - argv[1]=ft2232 Debug: 36 16 command.c:68 script_debug(): command - ft2232_device_desc Debug: 37 16 command.c:77 script_debug(): ft2232_device_desc - argv[0]=ocd_ft2232_device_desc Debug: 38 16 command.c:77 script_debug(): ft2232_device_desc - argv[1]=Amontec JTAGkey A Debug: 40 16 command.c:68 script_debug(): command - ft2232_layout Debug: 41 16 command.c:77 script_debug(): ft2232_layout - argv[0]=ocd_ft2232_layout Debug: 42 16 command.c:77 script_debug(): ft2232_layout - argv[1]=jtagkey Debug: 44 16 command.c:68 script_debug(): command - ft2232_vid_pid Debug: 45 16 command.c:77 script_debug(): ft2232_vid_pid - argv[0]=ocd_ft2232_vid_pid Debug: 46 16 command.c:77 script_debug(): ft2232_vid_pid - argv[1]=0x0403 Debug: 47 16 command.c:77 script_debug(): ft2232_vid_pid - argv[2]=0xcff8 Debug: 49 16 command.c:68 script_debug(): command - jtag_khz Debug: 50 16 command.c:77 script_debug(): jtag_khz - argv[0]=ocd_jtag_khz Debug: 51 16 command.c:77 script_debug(): jtag_khz - argv[1]=30 Debug: 52 16 core.c:1251 jtag_config_khz(): handle jtag khz User : 53 16 command.c:396 command_print(): 30 kHz Debug: 55 16 command.c:68 script_debug(): command - reset_config Debug: 56 16 command.c:77 script_debug(): reset_config - argv[0]=ocd_reset_config Debug: 57 16 command.c:77 script_debug(): reset_config - argv[1]=srst_only Debug: 58 16 command.c:77 script_debug(): reset_config - argv[2]=srst_pulls_trst Debug: 59 16 tcl.c:360 jim_newtap_cmd(): Creating New Tap, Chip: sam7se512, Tap: cpu, Dotted: sam7se512.cpu, 8 params Debug: 60 16 tcl.c:376 jim_newtap_cmd(): Processing option: -irlen Debug: 61 16 tcl.c:376 jim_newtap_cmd(): Processing option: -ircapture Debug: 62 16 tcl.c:376 jim_newtap_cmd(): Processing option: -irmask Debug: 63 16 tcl.c:376 jim_newtap_cmd(): Processing option: -expected-id Debug: 64 16 core.c:1099 jtag_tap_init(): Created Tap: sam7se512.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf Debug: 65 16 target.c:4215 jim_target(): Target command params: Debug: 66 16 target.c:4216 jim_target(): target create sam7se512.cpu arm7tdmi -endian little -chain-position sam7se512.cpu -variant arm7tdmi Debug: 68 16 command.c:68 script_debug(): command - bank Debug: 69 16 command.c:77 script_debug(): bank - argv[0]=ocd_flash_bank Debug: 70 16 command.c:77 script_debug(): bank - argv[1]=at91sam7 Debug: 71 16 command.c:77 script_debug(): bank - argv[2]=0 Debug: 72 16 command.c:77 script_debug(): bank - argv[3]=0 Debug: 73 16 command.c:77 script_debug(): bank - argv[4]=0 Debug: 74 16 command.c:77 script_debug(): bank - argv[5]=0 Debug: 75 16 command.c:77 script_debug(): bank - argv[6]=0 Debug: 76 16 command.c:77 script_debug(): bank - argv[7]=0 Debug: 77 16 command.c:77 script_debug(): bank - argv[8]=0 Debug: 78 16 command.c:77 script_debug(): bank - argv[9]=0 Debug: 79 16 command.c:77 script_debug(): bank - argv[10]=0 Debug: 80 16 command.c:77 script_debug(): bank - argv[11]=0 Debug: 81 16
Re: [Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey
But what do you suggest, what should I change in the inf file? First it was tested without the MI_00 and MI_01. Only ine line. But this was not working too. Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Montag, 15. Juni 2009 14:53 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey On Mon, Jun 15, 2009 at 8:51 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 14, 2009 at 10:01 PM, Michael Fischerfische...@t-online.de wrote: I want to create a debug version to find the problem. Attached is the inf file from the JTAGkey. It looks that the problem is inside the ftdi_usb_open_desc function. Here the bus-devices is 0 every time. Actually now looking at your inf and I think you have a problem with the inf file. You are using libusb-win32 for the individual device, not the whole device. The correct way is to use libusb-win32 for the whole device. I meant to say You are using libusb-win32 for the individual interface (which is part of the two interfaces configured), not the whole device. ;-- ; Devices ;-- [Devices] Amontec JTAGkey ( Channel A )=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00 Amontec JTAGkey ( Channel B )=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01 [Devices.NT] Amontec JTAGkey ( Channel A )=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00 Amontec JTAGkey ( Channel B )=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01 [Devices.NTAMD64] Amontec JTAGkey ( Channel A )=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00 Amontec JTAGkey ( Channel B )=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01 Reference: http://article.gmane.org/gmane.comp.lib.libusb.devel.windows/2088 -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD license vs D2XX library
Hello List, some notes on the libftdi version and performance. I have tested the r2240 with libftdi an could achive about 140KB/sec. Unfortunately I could not test the fd2xx with r2240, here it looks that it is broken. But the r1888 with ftd2xx looks like the same performance, here about 140KB/sec too. I will double check it again if a SVN build is working with libftdi and ftd2xx. Tested on WindowsXP and Insight. Download a huge file into RAM of the target. From the point of performance I think we can switch. The other problem is the installed ftd2xx base. I think it makes a problem to install a libftdi driver over an existing ftd2xx driver. Before the user can use a new windows version of OpenOCD based on libftdi, they must deinstall the ftd2xx driver with FTClean. This is possible and was working here. But how does the functionality looks like if we compare libftdi against the ftd2xx driver? Will the new high speed hardware supported by the libftdi driver too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD license vs D2XX library
Hello List again, it looks that the system has choke on somthing from the last mail. Therefore, second try. Some notes on the libftdi version and performance. I have tested the r2240 with libftdi an could achive about 140KB/sec. Unfortunately I could not test the fd2xx with r2240, here it looks that it is broken. But the r1888 with ftd2xx looks like the same performance, here about 140KB/sec too. I will double check it again if a SVN build is working with libftdi and ftd2xx. Tested on WindowsXP and Insight. Download a huge file into RAM of the target. From the point of performance I think we can switch. The other problem is the installed ftd2xx base. I think it makes a problem to install a libftdi driver over an existing ftd2xx driver. Before the user can use a new windows version of OpenOCD based on libftdi, they must deinstall the ftd2xx driver with FTClean. This is possible and was working here. But how does the functionality looks like if we compare libftdi against the ftd2xx driver? Will the new high speed hardware supported by the libftdi driver too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD license vs D2XX library (part 2)
From the point of performance I think we can switch. The other problem is the installed ftd2xx base. I think it makes a problem to install a libftdi driver over an existing ftd2xx driver. Before the user can use a new windows version of OpenOCD based on libftdi, they must deinstall the ftd2xx driver with FTClean. This is possible and was working here. But how does the functionality looks like if we compare libftdi against the ftd2xx driver? Will the new high speed hardware supported by the libftdi driver too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey
Hello List, here I have a problem to get the JTAGkey working with libusb and libftdi under WindowsXP. I use the following versions: - libusb-win32: 0.1.12.1 - libftdi: 0.16 OpenOCD was build under cygwin with the following options: CFLAGS=-O0 -g ./configure --enable-maintainer-mode --disable-werror --disable-shared --ena ble-ft2232_libftdi I want to create a debug version to find the problem. Attached is the inf file from the JTAGkey. It looks that the problem is inside the ftdi_usb_open_desc function. Here the bus-devices is 0 every time. Best regards, Michael jtagkey.inf Description: Binary data openocd.cfg Description: Binary data Debug: 10 15 configuration.c:83 find_file(): found openocd.cfg Debug: 12 15 command.c:68 script_debug(): command - telnet_port Debug: 13 15 command.c:77 script_debug(): telnet_port - argv[0]=ocd_telnet_port Debug: 14 15 command.c:77 script_debug(): telnet_port - argv[1]= Debug: 16 15 command.c:68 script_debug(): command - gdb_port Debug: 17 15 command.c:77 script_debug(): gdb_port - argv[0]=ocd_gdb_port Debug: 18 15 command.c:77 script_debug(): gdb_port - argv[1]= Debug: 20 15 command.c:68 script_debug(): command - tcl_port Debug: 21 15 command.c:77 script_debug(): tcl_port - argv[0]=ocd_tcl_port Debug: 22 15 command.c:77 script_debug(): tcl_port - argv[1]= Debug: 24 15 command.c:68 script_debug(): command - gdb_memory_map Debug: 25 15 command.c:77 script_debug(): gdb_memory_map - argv[0]=ocd_gdb_memory_map Debug: 26 15 command.c:77 script_debug(): gdb_memory_map - argv[1]=enable Debug: 28 15 command.c:68 script_debug(): command - gdb_flash_program Debug: 29 15 command.c:77 script_debug(): gdb_flash_program - argv[0]=ocd_gdb_flash_program Debug: 30 15 command.c:77 script_debug(): gdb_flash_program - argv[1]=enable Debug: 32 15 command.c:68 script_debug(): command - interface Debug: 33 15 command.c:77 script_debug(): interface - argv[0]=ocd_interface Debug: 34 15 command.c:77 script_debug(): interface - argv[1]=ft2232 Debug: 36 15 command.c:68 script_debug(): command - ft2232_device_desc Debug: 37 15 command.c:77 script_debug(): ft2232_device_desc - argv[0]=ocd_ft2232_device_desc Debug: 38 15 command.c:77 script_debug(): ft2232_device_desc - argv[1]=Amontec JTAGkey A Debug: 40 15 command.c:68 script_debug(): command - ft2232_layout Debug: 41 15 command.c:77 script_debug(): ft2232_layout - argv[0]=ocd_ft2232_layout Debug: 42 15 command.c:77 script_debug(): ft2232_layout - argv[1]=jtagkey Debug: 44 15 command.c:68 script_debug(): command - ft2232_vid_pid Debug: 45 15 command.c:77 script_debug(): ft2232_vid_pid - argv[0]=ocd_ft2232_vid_pid Debug: 46 15 command.c:77 script_debug(): ft2232_vid_pid - argv[1]=0x0403 Debug: 47 15 command.c:77 script_debug(): ft2232_vid_pid - argv[2]=0xcff8 Debug: 49 15 command.c:68 script_debug(): command - jtag_khz Debug: 50 15 command.c:77 script_debug(): jtag_khz - argv[0]=ocd_jtag_khz Debug: 51 15 command.c:77 script_debug(): jtag_khz - argv[1]=30 Debug: 52 15 core.c:1239 jtag_config_khz(): handle jtag khz User : 53 15 command.c:396 command_print(): 30 kHz Debug: 55 15 command.c:68 script_debug(): command - reset_config Debug: 56 15 command.c:77 script_debug(): reset_config - argv[0]=ocd_reset_config Debug: 57 15 command.c:77 script_debug(): reset_config - argv[1]=trst_and_srst Debug: 58 15 command.c:77 script_debug(): reset_config - argv[2]=srst_pulls_trst Debug: 59 15 tcl.c:363 jim_newtap_cmd(): Creating New Tap, Chip: str710, Tap: cpu, Dotted: str710.cpu, 8 params Debug: 60 15 tcl.c:382 jim_newtap_cmd(): Processing option: -irlen Debug: 61 15 tcl.c:382 jim_newtap_cmd(): Processing option: -ircapture Debug: 62 15 tcl.c:382 jim_newtap_cmd(): Processing option: -irmask Debug: 63 15 tcl.c:382 jim_newtap_cmd(): Processing option: -expected-id Debug: 64 15 core.c:1089 jtag_tap_init(): Created Tap: str710.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf Debug: 65 15 target.c:4191 jim_target(): Target command params: Debug: 66 15 target.c:4192 jim_target(): target create str710.cpu arm7tdmi -endian little -chain-position str710.cpu -variant arm7tdmi Debug: 68 31 command.c:68 script_debug(): command - bank Debug: 69 31 command.c:77 script_debug(): bank - argv[0]=ocd_flash_bank Debug: 70 31 command.c:77 script_debug(): bank - argv[1]=str7x Debug: 71 31 command.c:77 script_debug(): bank - argv[2]=0x4000 Debug: 72 31 command.c:77 script_debug(): bank - argv[3]=0x0004 Debug: 73 31 command.c:77 script_debug(): bank - argv[4]=0 Debug: 74 31 command.c:77 script_debug(): bank - argv[5]=0 Debug: 75 31 command.c:77 script_debug(): bank - argv[6]=0 Debug: 76 31 command.c:77 script_debug(): bank - argv[7]=STR71x Debug: 78 31 command.c:68 script_debug(): command - bank Debug: 79 31 command.c:77 script_debug(): bank - argv[0]=ocd_flash_bank Debug: 80 31 command.c:77 script_debug(): bank - argv[1]=str7x Debug: 81 31 command.c:77 script_debug(): bank - argv[2]=0x400C Debug: 82 31 command.c:77 script_debug(): bank -
Re: [Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey (part2)
Hello Xiaofan, I have not tried the SVN version. Do you know if the SVN version contain binaries too? Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Montag, 15. Juni 2009 01:42 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey (part2) On Sun, Jun 14, 2009 at 10:59 PM, Michael Fischerfische...@t-online.de wrote: the problem was that the libusb 0.1.12.1 does not support composite devices. But you will find a fix here: http://www.nabble.com/LibUSB---composite-USB-devices-td11027391.html Have you tried the SVN version of libusb-win32? It may have already the fix integrated. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey (part2)
No. But it is very easy to build the binary using MinGW. Get the svn version of libusb-win32, under Msys, type make and you can build the binary. Are you sure, you do not need the Microsoft DDK? Best regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Montag, 15. Juni 2009 07:49 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] Problem to run r2240 with libusb/libftdi and a JTAGkey (part2) On Mon, Jun 15, 2009 at 1:45 PM, Michael Fischerfische...@t-online.de wrote: Hello Xiaofan, I have not tried the SVN version. Do you know if the SVN version contain binaries too? No. But it is very easy to build the binary using MinGW. Get the svn version of libusb-win32, under Msys, type make and you can build the binary. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding simulated target support for regression testing purposes
Hello Zach,
it looks that the 1893 solve the problem here with the SAM7.
Only a short test with the SAM7 and LPC2294. I have compare
the jtag.c and ft2232.c against my 1888+patch version. Both
files are equal. Therefore I suppose that the 1893 is working
like the 1888+patch here. In the moment no time for a new
big smoke test.
Regards,
Michael
-Ursprüngliche Nachricht-
Von: Zach Welch [mailto:z...@superlucidity.net]
Gesendet: Sonntag, 24. Mai 2009 01:53
An: David Brownell
Cc: openocd-development@lists.berlios.de; Michael Fischer
Betreff: Re: [Openocd-development] Adding simulated target support for
regression testing purposes
On Thu, 2009-05-21 at 16:54 -0700, David Brownell wrote:
On Thursday 21 May 2009, Michael Fischer wrote:
It looks that these JTAG interfaces have not the same behaviour.
One point could be the RESET signals SRST and TRST. Here the
FT2232 can set both signals at the same time, which I think
is used too.
Yeah, I noticed that *sometimes* an ft2232 adapter was able
to come up OK ... but other times it needed a reset.
I was wondering if the issue was maybe that the JTAG link
wasn't getting properly reset ... either by TRST or some
other process.
This seems highly buglike to me.
Has this problem been resolved in r18{90,92,93}?
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding simulated target support for regression testing purposes
Hello David,
I was running with the ft2232 and jtag patches ('92, '93),
and they didn't seem to resolve that issue.
Which issue didn't seem to resolve?
In which case you have problems, with which targets?
Regards,
Michael
-Ursprungliche Nachricht-
Von: David Brownell [mailto:davi...@pacbell.net]
Gesendet: Sonntag, 24. Mai 2009 06:13
An: Zach Welch
Cc: openocd-development@lists.berlios.de; Michael Fischer
Betreff: Re: [Openocd-development] Adding simulated target support for
regression testing purposes
On Saturday 23 May 2009, Zach Welch wrote:
.
One point could be the RESET signals SRST and TRST. Here the
FT2232 can set both signals at the same time, which I think
is used too.
Yeah, I noticed that *sometimes* an ft2232 adapter was able
to come up OK ... but other times it needed a reset.
I was wondering if the issue was maybe that the JTAG link
wasn't getting properly reset ... either by TRST or some
other process.
This seems highly buglike to me.
Has this problem been resolved in r18{90,92,93}?
I was running with the ft2232 and jtag patches ('92, '93),
and they didn't seem to resolve that issue. It was still
not guaranteed that the server could start up properly
without a reset in the recent past. It's not clear if
they changed anything I was noticing (or not).
Newish behavior: doing a reset later doesn't necessarily
fix things. scan_chain stays the same. Need to abort
the server, then restart it.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Correct script to flash the lpc-2148
Hello Xiaofan, I have not tried to use flashing so far. So today I tried to learn how to flash the LPC2148 on board of the Olimex LPC-P2148. I tried to halt the target and then use flash write_image isoc_io_sample.hex 0x0 ihex but this does not seem to work. Here I have a Olimex LPC-P2148 board too, tested with a FT2232 device under windows, with the r1893. For testing, I have a short hex file, called test_rom.hex 1) flash write_image test_rom.hex 0x0 2) dump_image dump.bin 0x0 364 After this I got a file dump.bin on my HD. Now I convert the hex file to a bin file with: arm-elf-objcopy -I ihex -O binary test_rom.hex test_rom.bin After this I compare the test_rom.bin with the dump.bin file. Both files are equal! Attached are the file which I use for testing. If you like send me your file that I can test it here too. Best regards, Michael test_rom.hex Description: Binary data jtagkey.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
Hello Xiaofan, With your script, I can flash the files and I can halt the target. However the flashing is apparently not correct as it does not work. Using lpc21isp it works. first of all I think it is a checksum problem which control a valid user code. Take a look in the LPC2148 user manual. In you startup code the checksum was missing. 4.2 Criterion for a valid user code It is possible that the lpc21isp calculated the correct checksum and placed it in you code. But it could be possible that the J-Link had a problem too. Have other users problem with flashing the LPC2148? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
Hello list, now I could reproduce the problem here with the original Olimex BLINK example. It will not work, the problem is the checksum. The startup code looks like: _vectors: ldr PC, Reset_Addr ldr PC, Undef_Addr ldr PC, SWI_Addr ldr PC, PAbt_Addr ldr PC, DAbt_Addr nop /* Reserved Vector (holds Philips ISP checksum) */ In this case the bootloader will start, and not the application. Now I take a look in the openocd manual and found the following information: 13.2.2.1 lpc2000 options flash bank lpc2000 base size 0 0 target variant clock [calc checksum] ...and the optional keyword calc checksum, telling the driver to calculate a valid checksum for the exception vector table. If I use now the calc_checksum options in my cfg file: flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum I got the following output from OpenOCD: flash write_image main.hex 0x0 Verification will fail since checksum in image(0xe1a0) written to flash was different from calculated vector checksum(0xb9205f84). To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 756 byte from file main.hex in 0.171875s (4.295455 kb/s) The new checksum was calculated, and the program is working. An other solution is, to change the startup code like: _vectors: ldr PC, Reset_Addr ldr PC, Undef_Addr ldr PC, SWI_Addr ldr PC, PAbt_Addr ldr PC, DAbt_Addr .word 0xb9205f84 In this case the correct checksum is set, and the program should work too. Attached is the main.hex file which should work with the lpc2148 without the calc_checksum key. LED1 and LED2 are flashing. Best regards, Michael main.hex Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New trunk 1906
Hello List, I have added the options calc_checksum to the flash driver of the LPC2148 target. This was forgotten here. All other LPC targets use this option. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
Hello Xiaofan, I have tesed to flash the program here. I could flash it with my ft2232 device. I do not check the functionality of the program itself, LED1 was flashing. 2) And it seems to have reset/halt problem. This is correct, I could not get in contact with OpenOCD. And I could not get in contact with the original segger sw and try to erase the CPU. Here I must use FlashMagic and the ICSP interface to erase the CPU. Is it possible that the application switch of the JTAG interface here? Best regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 24. Mai 2009 16:02 An: Michael Fischer Cc: Openocd-Dev; z...@superlucidity.net Betreff: Re: [Openocd-development] Correct script to flash the lpc-2148 On Sun, May 24, 2009 at 8:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Sun, May 24, 2009 at 7:03 PM, Michael Fischer fische...@t-online.de wrote: Attached is the main.hex file which should work with the lpc2148 without the calc_checksum key. LED1 and LED2 are flashing. Yes this works well with my V3 Black Jlink. The two LEDs are flashing now. I updated to the latest SVN with your updated lpc2148.cfg. I will try some other hex files. Thanks a lot for debugging the problems for me. So I used a big hex file from JCWren's example. http://jcwren.com/arm/packages/LPC2148_Demo_v144.tgz OpenOCD does not seem to work. 1) The resultant device is only partial working. There is a virtual com port now but I can not talk to with gtkterm/cutecom. 2) And it seems to have reset/halt problem. Maybe you can give it a try. I will also try it with a V6 yellow J-Link tomorrow. mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3/flash$ openocd -f jlink.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-24-21:41) svn:1906 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ 30 kHz Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Info : JLink hw version 3 Info : Vref = 3.285 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 255 Info : J-Link JTAG Interface ready Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Warn : DBGACK set while target was in unknown state. Reset or initialize target. target state: halted target halted in Thumb state due to breakpoint, current mode: Supervisor cpsr: 0xa0f3 pc: 0x7fffd2c4 30 kHz Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0xa0f3 pc: 0x7fffd2c0 requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0xa0d3 pc: 0x 1500 kHz Info : accepting 'telnet' connection from 0 TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---||-|||--|--|- -|- 0 | lpc2148.cpu|Y| 0x4f1f0f0f | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0c target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0xa0d3 pc: 0x Warn : Verification will fail since checksum in image(0xe59ff004) written to flash was different from calculated vector checksum(0xb9205f88). Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 232748 byte from file lpc2148.hex in 27.502781s (8.264363 kb/s) 30 kHz Error: JTAG communication failure, check connection, JTAG interface, target power etc. Error: trying to validate configured JTAG chain anyway... Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x00. tap=lpc2148.cpu pos=0 expected 0x1 got 0 Warn : Could not validate JTAG chain, continuing anyway... Warn : value captured during scan didn't pass the requested check: Warn : captured: 0x00 check_value: 0x01 check_mask: 0x0F Runtime error, file embedded:startup.tcl, line 177: examine-fails: -104 Runtime error, file command.c, line 453: Error: timed out while waiting for target halted Runtime error, file command.c, line 453: target state: running Error: timed out while waiting for target halted Runtime error, file command.c, line 453: ^C mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3/flash$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger scan_chain TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---||-|||--|--|- -|- 0 | lpc2148.cpu
[Openocd-development] SAM7S256 still broken, by 1889 too
Hello list, the SAM7S256 is still broken like I have reported before: https://lists.berlios.de/pipermail/openocd-development/2009-May/006929.html The OpenOCD output looks like: = C:\Temp\SAM7S256Testopenocd-1889 -f .\prj\jtagkey.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-23-09:57) svn:1889 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ 30 kHz Info : JTAG tap: sam7s256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) Info : JTAG Tap/device matched 30 kHz Info : JTAG tap: sam7s256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) Info : JTAG Tap/device matched Warn : srst pulls trst - can not reset into halted mode. Issuing halt after rese t. Warn : value captured during scan didn't pass the requested check: Warn : captured: 0x0F check_value: 0x01 check_mask: 0x0F Error: timed out while waiting for target halted Runtime error, file embedded:startup.tcl, line 212: expected return code but got 'TARGET: sam7s256.cpu - Not halted' Runtime error, file .\prj\jtagkey.cfg, line 99: = Attached is the d3 log file too. Please apply the patch from Magnus, which was send here too: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html - jtag_090522.patch - ft2232_090522.patch This solve the problem. All the three patches was tested against 1881 with the following targets under Windows and FT2232: SAM7S256, SAM7X256, AT91R40008, SAM7SE512, LPC2148, LPC2294, STR710, STM32F103ZE. Tested was RAM debugging under Insight. The same test with SAM7S256 LPC2148, LPC2294 STR710, STM32F103ZE was done under Mac OS X with FT2232 and J-Link, RAM debugging under Eclipse. Regards, Michael Debug: 9 0 configuration.c:83 find_file(): found .\prj\jtagkey.cfg Debug: 11 0 command.c:88 script_command(): script_command - telnet_port Debug: 12 0 command.c:105 script_command(): script_command - telnet_port, argv[0]=ocd_telnet_port Debug: 13 0 command.c:105 script_command(): script_command - telnet_port, argv[1]= Debug: 15 0 command.c:88 script_command(): script_command - gdb_port Debug: 16 0 command.c:105 script_command(): script_command - gdb_port, argv[0]=ocd_gdb_port Debug: 17 0 command.c:105 script_command(): script_command - gdb_port, argv[1]= Debug: 19 0 command.c:88 script_command(): script_command - tcl_port Debug: 20 0 command.c:105 script_command(): script_command - tcl_port, argv[0]=ocd_tcl_port Debug: 21 0 command.c:105 script_command(): script_command - tcl_port, argv[1]= Debug: 23 0 command.c:88 script_command(): script_command - gdb_memory_map Debug: 24 0 command.c:105 script_command(): script_command - gdb_memory_map, argv[0]=ocd_gdb_memory_map Debug: 25 0 command.c:105 script_command(): script_command - gdb_memory_map, argv[1]=enable Debug: 27 0 command.c:88 script_command(): script_command - gdb_flash_program Debug: 28 0 command.c:105 script_command(): script_command - gdb_flash_program, argv[0]=ocd_gdb_flash_program Debug: 29 0 command.c:105 script_command(): script_command - gdb_flash_program, argv[1]=enable Debug: 31 0 command.c:88 script_command(): script_command - interface Debug: 32 0 command.c:105 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 33 0 command.c:105 script_command(): script_command - interface, argv[1]=ft2232 Debug: 35 0 command.c:88 script_command(): script_command - ft2232_device_desc Debug: 36 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 37 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[1]=Amontec JTAGkey A Debug: 39 0 command.c:88 script_command(): script_command - ft2232_layout Debug: 40 0 command.c:105 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout Debug: 41 0 command.c:105 script_command(): script_command - ft2232_layout, argv[1]=jtagkey Debug: 43 0 command.c:88 script_command(): script_command - ft2232_vid_pid Debug: 44 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid Debug: 45 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[1]=0x0403 Debug: 46 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[2]=0xcff8 Debug: 48 0 command.c:88 script_command(): script_command - jtag_khz Debug: 49 0 command.c:105 script_command(): script_command - jtag_khz, argv[0]=ocd_jtag_khz Debug: 50 0 command.c:105 script_command(): script_command - jtag_khz, argv[1]=30 Debug: 51 0 jtag.c:2787 handle_jtag_khz_command(): handle jtag khz User : 52 0 command.c:380 command_print(): 30 kHz Debug: 54 0 command.c:88 script_command(): script_command - reset_config Debug: 55 0 command.c:105
[Openocd-development] SAM7S256 still broken, by 1889 too
Hello Freddie, response to: https://lists.berlios.de/pipermail/openocd-development/2009-May/007113.html here it is working with a LPC2148, tested with r1888 and the pathes from Magnus: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html Can you test it with the jtag_090522.patch and ft2232_090522.patch too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SVN revision in Windows
Hello Freddie, have you installed SVN under Cygwin too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Big smoketest with r1888 and the 3 patches from Magnus
Hello list, I have make a new smoketest with the r1888 and the patches which can be find here: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html Tested under Windows with FT2232 and the following targets: LPC2148, LPC2294, SAM7S256, SAM7X256, SAM7SE512, AT91R40008, STR710 and STM32. The same like before, debugging in RAM/ROM with Insight and Eclipse. In case of SAM7SE512, AT91R40008 and STM32 debugging in RAM only. The same test was done under Mac OS X with a FT2232 and a J-Link (V6) with the following targets: LPC2148, LPC2294, SAM7S256, STR710 and STM32. Here debugging with Eclipse only, and in case of STM32 debugging in RAM only. Everything was working for me. Therefore I think the two outstanding patches can be applied too: - jtag_090522.patch - ft2232_090522.patch Btw, the SAM7xxx settings must be changed becasue of the new flash driver. I will do this with a patch next. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SAM7S256 still broken, by 1889 too
Hello Zach, the outstanding patches are required to get the SAM7 working. In case of the LPC, I must use the delay here too for my LPC2148 and LPC2294 targets. Without the delay sometimes the LP2294 is working and sometimes not. It works more stable with the delay. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 is broken by 1825
Hello Øyvind, Does svn head work if you use 1824 for ft2232.c only? I have make a new test, copy of the 1872 do not help only. I must use the long sequence too: tms_sequence long This mean, I must copy the 1824 over the 1872 and use the long sequence to get the SAM and LPC working. Best regards, Michael -Ursprüngliche Nachricht- Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag von Øyvind Harboe Gesendet: Donnerstag, 21. Mai 2009 18:11 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] SAM7S256 is broken by 1825 On Thu, May 21, 2009 at 4:43 PM, Michael Fischer fische...@t-online.de wrote: Hello list, reference is made to Strange behavior with r1857 and SAM7S256: https://lists.berlios.de/pipermail/openocd-development/2009-May/006929.html The last version which is working is the r1824, the r1825 makes the problems. Does svn head work if you use 1824 for ft2232.c only? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 is broken by 1825
Does svn head work if you use 1824 for ft2232.c only?
No, it does not change.
I got a hint from Magnus to disable the following part from ft2232.c:
#if 0
/* This is (or should) be handled in jtag_add_reset */
if ( (cmd-cmd.reset-trst == 1) || ( cmd-cmd.reset-srst
(jtag_reset_config RESET_SRST_PULLS_TRST) ) )
{
tap_set_state(TAP_RESET);
}
#endif
This will solve the SAM7S256 problem, but move the problem
to my LPC2294.
It looks that we have a RESET problem, could it be?
Tested with 1872 here.
Best regards,
Michael
-Ursprüngliche Nachricht-
Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag
von Øyvind Harboe
Gesendet: Donnerstag, 21. Mai 2009 18:11
An: Michael Fischer
Cc: Openocd-Dev
Betreff: Re: [Openocd-development] SAM7S256 is broken by 1825
On Thu, May 21, 2009 at 4:43 PM, Michael Fischer fische...@t-online.de
wrote:
Hello list,
reference is made to Strange behavior with r1857 and SAM7S256:
https://lists.berlios.de/pipermail/openocd-development/2009-May/006929.html
The last version which is working is the r1824, the r1825 makes
the problems.
Does svn head work if you use 1824 for ft2232.c only?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Adding simulated target support for regression testing purposes
Hello Øyvind, How about adding the sim interface target? For me it looks that we have problem with real hardware, which we will not find in simulation. In the moment for example the J-Link is working with my SAM7S target and the ft2232 had some problems, but why? It looks that these JTAG interfaces have not the same behaviour. One point could be the RESET signals SRST and TRST. Here the FT2232 can set both signals at the same time, which I think is used too. But the J-Link can not set both signals at the same time. We should reduce it to a common denominator, and try to use the SRST and TRST signal in the FT2232 like the J-Link. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Request of feature freeze
Hello list, we should try to stabilize the functionality of OpenOCD. For me it looks that in the last time a lot of functionality was changed, and these was tested only on one target/interface. This is not a charge, it is normal if the developer had only one target for testing. But if I start a smoketest, I have problems that one target is working, and one not. After this the most time I need to binary search which version was working, and at which version the problem start. You are to fast of starting new features/updates to the SVN. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] version.texi will not create under Mac OS X, r1857
Hello list, in case of my cygwin build under windows the version.texi will be created. But in case of Mac OS X not. Any hints where I can take a look at? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Strange behavior with r1857 and SAM7S256 (part2)
Hello list, even the same problem with the 1857 if I use the long tms sequence: tms_sequence long Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Short state table enabled as of r1827
Hello Øyvind, yes the same behaviour with a LPC2148 here. Regards, Michael -Ursprüngliche Nachricht- Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag von Øyvind Harboe Gesendet: Montag, 18. Mai 2009 22:05 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] Short state table enabled as of r1827 Does the LPC2148 (which I have) exhibit the same problem? I can not test the attached patch here, but it is intended to allow switching between the long(old) or new (short) tms_sequence tables. The patch uses the short table as default. Try: tms_sequence long tms_sequence short -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] How to build a static version under Mac OS X?
Hello list, I want to build a static version under Mac OS X. But the new build with the libtool produce some libraries too. I do not understand why this was changed, does it have any advantages? In the moment it looks that it need more time to build. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to build a static version under Mac OS X?
Hello Rick, I believe you can disable the building of the shared library with -- disable-shared to configure. Thanks, this works here. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD: Speed test on STR710 target
Hello Nicolas, Try like 5 measurements for each versions. You may discover that speed measurement is not stable across multiple tests on the same version. Yes I know this, but the differences was between 1 and 3 KB/sec. And this differences to not explain the differences itself. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] AT91SAM7 Flash
Hello Øyvind, you have changed the name from the new driver, here you have removed the _new? In this case the cfg files with the old driver name will work with the new driver. But the new driver had other parametes, could it be? Have you change the cfg files too? I found the following info in the source file: flash bank at91sam7 0 0 0 0 0 (old style, full auto-detection) === NOT RECOMENDED !!! Could this be a problem now? The new parameter should no: flash bank at91sam7 0 0 0 0 0 0 0 0 0 0 0 0 25000 (auto-detection, except for clock) Is this the clock of the external crystal? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD: Speed test on STR710 target
Hello List, I have tested the speed from 1606 with the patch from Magnus and the 1787 with a FT2232 under Windows. The target was a STR710 with external RAM. A very old speed table from r657 can be found here: http://www.yagarto.de/projects/jtagspeed/index.html#result Here the FT2232 had a speed in the past about 165KB/sec on a STR710 target. I have repeated the test again, here are the results: - 657: 164KB/sec - 1606: 148KB/sec - 1787: 149KB/sec This is a speed decrease from about 9% Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD: Speed test on STR710 target
Hello Øyvind, What's your standard deviation? Do you mean the normal speed in case of single step for example? I could not see *huge* differences here. It feels like the same speed on all 3 versions. Regards, Michael -Ursprüngliche Nachricht- Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag von Øyvind Harboe Gesendet: Freitag, 15. Mai 2009 23:15 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] OpenOCD: Speed test on STR710 target Voodoo? What's your standard deviation? Nicolas Pitre showed it to be *huge* in his case... Could be a red herring... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] r1770, load_image ist not working here
Hello List, it is possible that I have make to much testing here and mixed something. I will start with a clean build. What I find curious about the lpc2294.cfg and your posting above is that working memory is at 0x4000. It is a olimex LPC-2294 board with external RAM. I will test it again with the 1606 and 1770. Regards, Michael -Ursprüngliche Nachricht- Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag von Øyvind Harboe Gesendet: Mittwoch, 13. Mai 2009 21:32 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] r1770, load_image ist not working here Referring to our offlist discussion: 1606 has the same problem per your testing. What I find curious about the lpc2294.cfg and your posting above is that working memory is at 0x4000. Does the lpc2294 have two ram regions? Could it be that the config script is busted and that working memory address is wrong? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] r1770, load_image ist not working here
Hello list, here is a new test which I had make with r1606 / r1770, done with a FT2232 device. The result look like: Windows-ft2232-1606 Open On-Chip Debugger version Open On-Chip Debugger 0.2.0-in-development (2009-05-13-21:55) svn:1606 load_image testimg.bin 0x8100 2466976 byte written at address 0x8100 downloaded 2466976 byte in 111.546875s dump_image win-1606.bin 0x8100 2466976 Windows-ft2232-1770 Open On-Chip Debugger version Open On-Chip Debugger 0.2.0-in-development (2009-05-13-22:03) svn:1770 load_image testimg.bin 0x8100 2466976 byte written at address 0x8100 downloaded 2466976 byte in 111.562500s dump_image win-1770.bin 0x8100 2466976 timeout waiting for SYSCOMP DBGACK, last DBG_STATUS: 2 The file on the harddisk had a size of 2030560 and not the full size of 2466976. Attached is the cfg file too. OpenOCD was build with: ./bootstrap ./configure --enable-maintainer-mode --disable-werror --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/mfischer/openocd/ftd2xx CC=gcc -mno-cygwin Best regards, Michael jtagkey.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build problem with 1770 and Mac OS X
Hello list, please can some one test if it is possible to build the 1770 on Mac OS X? Here I need libtoolize, but this was not found, even if I install libtool over mac port. I only found glibtoolize, therefore I set a symbolic link to libtoolize. But at the end, I got a ld error like: ld: duplicated symbol _Jim_SetResult_sprintf Mac OS X 10.5.7 and GCC 4.0.1 I had no problems with the old build where libtoolize is not needed. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Big smoketest with r1606 (Windows / Mac OS X)
Hello list, I have make a big smoketest with the r1606. But this is not an original r1606, some small modifications was made. Many thanks to Magnus Lundin to solve the problems here. #1, problem with SAM7S and old flash driver at91sam7_old.c, here near line 370, the line: at91sam7_old_info-num_planes = 1; was placed befor: at91sam7_old_read_clock_info(bank); Now it looks like: /* Read main and master clock freqency register */ at91sam7_old_info-num_planes = 1; at91sam7_old_read_clock_info(bank); #2, problem to get the J-Link working == jtag.c, the malloc from jtag_build_buffer was replaced by calloc: bit_count = jtag_scan_size(cmd); //*buffer = malloc(CEIL(bit_count, 8)); *buffer = calloc(1,CEIL(bit_count, 8)); #3, J-Link === Here I use the jlink.c from 1686 instead of 1606 How the smoketest was done. The test was done with the following targets: LPC2148, LPC2294, STR710, AT91R4008, SAM7S256, SAM7X256, SAM7SE512 and STM32F103ZE. Windows (FT2232) = In case of Windows only the FT2232 was tested, here with a JTAGkey. First with Insight, here the program was downloaded into RAM. I played a little with the debugger. Close the debugger, and start again with a RAM download. After this the program was downloaded into Flash. The same procedure, twice time. Now telnet is used to check if the flash is empty, and to erase the flash. After the Insight session, I use Eclipse. Here the same procedure with RAM / ROM, twice time. And check/erase with telnet. Exception: - In case of AT91R4008, SAM7SE512 and STM32F103ZE only the RAM test was made. Resources: - WindowsXP SP2 - Eclipse 3.4.1 with Zylin plugin 4.5.1 Mac OS X (FT2232/J-Link) = Here the J-Link and FT2232 was used, but only with Eclipse. The test was made with only LPC2148, LPC2294, STR710, SAM7S256 and STM32F103ZE. But each test with FT2232 and J-Link. Exception: - In case of STM32F103ZE only the RAM test was made. Resources: - Mac OS X, 10.5.6 (intel) - Eclipse 3.4.1 with Zylin plugin 4.5.1 - J-Link (V8) I have created no patch, because the actual version is to much away from 1606. It looks that the 1606 have some problems with the following commands and big data to transfer: monitor arm7_9 fast_memory_access enable monitor arm7_9 dcc_downloads enable monitor verify_ircapture disable Here my speed test do not work stable. But this need further inquiries, which I should make with the head version too. Btw, binaries can be found at my page: http://www.yagarto.de/ Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SAM7S256 problems (bus error and flash driver not found)
Hello list, here I am using a jtagkey and a SAM7S256 eval board under Mac OS X. With r1606 I got a bus error in case of using the following commands under GDB: target remote localhost: But it was working with LPC2148 and STR/10 target. Now I try to use the 1678, but here I got the error that the flash driver at91sam7 could not be found. The same problem with 1686, flash driver at91sam7 could not be found. Please can some one test it too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SAM7S256 problems (bus error and flash driver not found) (part 2)
Hello list, With r1606 I got a bus error in case of using the following commands under GDB: target remote localhost: Some more information about the bus error. I found a working solution which is the r1461. This was the version I use for the Mac install. I got a fresh version from the SVN and use the same configure script and so on. r1461 works, but 1606 not. Btw. ft2232 interface was used. You are to fast with the update of the SVN, no time to check against all the targets. I do not like the binary search for the wrong version :o( Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SAM7S256 problems (bus error and flash driver not found) (part 2)
Hello, it looks that r1461 is working but r1462 not anymore, in case of the bus error. Who has commited the r1462? Upps, I had commited the changes from Zach here. @Zach please can you take a look at your patches again? - openocd-flash-static-keyword-v3.patch - openocd-lpc2000-fix-erase-obo.patch - openocd-jlink-fix-sign-ptr-warn.patch - openocd-wextra-etm.patch - openocd-wextra-jtag.patch - openocd-add-new-tap-symbols-v6.patch Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Mac OS X: Broken build 1621 and above (part 2)
Hello list,
sorry I have interpret the messages in a wrong way, now I found
the problem, and a way to fix it.
flash_address could not found by some of the cfi functions:
__inline__ u32 flash_address(flash_bank_t *bank, int sector, u32 offset)
{
/* while the sector list isn't built, only accesses to sector 0 work */
For testing I have replace the __inline__ by static like:
static u32 flash_address(flash_bank_t *bank, int sector, u32 offset)
{
/* while the sector list isn't built, only accesses to sector 0 work */
Now the linker is happy, but I do not know which effect this have in
case of performance.
Even the problem exist with Xcode 3.1.2 if I do not change the __inline__
Best regards,
Michael
-Ursprungliche Nachricht-
Von: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de]im Auftrag von Zach
Welch
Gesendet: Donnerstag, 7. Mai 2009 22:31
An: Michael Fischer
Cc: Openocd-Dev
Betreff: Re: [Openocd-development] Mac OS X: Broken build 1621 and above
(part 2)
On Thu, 2009-05-07 at 21:27 +0200, Michael Fischer wrote:
Hello List,
the problem with r1621 can be solved if AC_PROG_CC_C99
is removed from configure.in. In this cas we have r1620.
But this is not solving the problem in the last version
r1649 if I remove AC_PROG_CC_C99 here too.
Can you provide more details about the C99 breakage? You are the first
person to report a problem, so I figure there is a workaround Darwin.
Cheers
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Mac OS X: Broken build 1621 and above (part 2)
Hello Rick, Your patch is working. I found this out for some minutes too. And changed it to static __inline__ like in parport.c and gdb_server.c But I had problems to commit from my Mac here. I have send Oyvind a message and asked if he commit it in the next patch from him. I think you can commit it. Many thanks for the explanation with the -O0 mistake here. Best regards, Michael -Ursprungliche Nachricht- Von: Rick Altherr [mailto:kc8...@kc8apf.net] Gesendet: Freitag, 8. Mai 2009 20:47 An: Michael Fischer Cc: Zach Welch; Openocd-Dev Betreff: Re: AW: [Openocd-development] Mac OS X: Broken build 1621 and above (part 2) It looks like flash_address() is missing a prototype in cfi.c which is causing link problems, but only if you are building -O0. You do that accidentally by overriding CFLAGS. The default CFLAGS is '-g -O2', but by setting it to '-I/opt/local/libusb-0.1.12/include' gcc defaults back to -O0. Specifically, flash_address is defined in cfi.c and has the __inline__ attribute but there is no prototype. For -O0, inlining is ignored, so the callsites expect a function named flash_address to be generated, but gcc seems to not do so. For -O2, the callsites are inlined, so it builds. Please try the attached patch. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Mac OS X: Broken build 1621 and above
Hello List, the last version I could build on Mac OS X was 1620, after this I got unresolved symbols from libflash. A lot of cfi functions could not be found. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Mac OS X: Broken build 1621 and above (part 2)
Hello List, the problem with r1621 can be solved if AC_PROG_CC_C99 is removed from configure.in. In this cas we have r1620. But this is not solving the problem in the last version r1649 if I remove AC_PROG_CC_C99 here too. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Mac OS X compile fixes
Hello List,
The first patch seemed a no brainer and the second didn't
look very controversial... Backed it out now...
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/jim.c
===
--- src/helper/jim.c (revision 1596)
+++ src/helper/jim.c (working copy)
@@ -11984,7 +11984,7 @@
if (argc == 1) {
-#if !defined(HAVE_UNISTD_H) || IS_DARWIN
+#ifndef HAVE_UNISTD_H
extern char **environ;
#endif
Why do you have remove the patch, and use the old solution?
This patch was a fix to compile it under Mac OS X. Better to have
a working solution and make the improvement later, than to have a no
working solution.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build problem with r1588, jim.c
Hello List,
I have problem to build jim.c under Mac OS X.
Here the old version looks like:
static int Jim_EnvCoreCommand(Jim_Interp *interp, int argc,
Jim_Obj *const *argv)
{
const char *key;
char *val;
if (argc == 1) {
#ifndef _WIN32
extern char **environ;
#endif
Which was working, but in the new one (r1588) _WIN32 was replaced by
HAVE_UNISTD_H.
HAVE_UNISTD_H was set to 1, but I need the extern char **environ; here to
compile.
Regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build problem with r1588, jim.c
Hello, the new version r1589 do not solve the problem, becasue the unistd.h looks like: #define getpagesize() PAGE_SIZE No information about environ here. Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink buffer size error?
Hello Magnus, I have just started to test a JLink interface, and looking through the code it seems that the JLINK_OUT_BUFFER_SIZE is wrong. It must be able to hold tms and tdi out + 4 command bytes. #define JLINK_OUT_BUFFER_SIZE2*2048+4 If you take a look at the EMU_CMD_HW_JTAG3 command, and with the info from 1.3.2 of the manual, you are right. The tms_buffer and the size of the tdi_buffer are both 2048. And we need the 4 byte header information too. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] J-Link interface status
Hello Alan, I noticed that using J-Link yellow version 6.0 OpenOCD can detects my ARM9 i.MX27 processor with no problem. Can you change some memory values too? Try to use mww to write some values and mdw to read it back. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] J-Link, different FW-Version, different behaviour
Hello List, I found out that I have a V6.0 which is working with the STR710 and one version not. The version which is NOT working is: J-Link ARM V6 compiled Apr 1 2008 11:56:10 The version which is working had the following version: J-Link ARM V6 compiled Jul 22 2008 11:42:42 Here the RAM write/read test is working, but had had some problem at first to detect the CPU. I will try to make some more test. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] J-Link, different FW-Version, different behaviour
Upps, there was a typo. The new version which is not working is: J-Link ARM V6 compiled Apr 1 2009 11:56:10 2009 and not 2008. Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Recent JLink churn
Hello List, I think it is very tricky to get the jlink to work with openocd. In the last time, a year ago, I think the r717 was working with STR710, SAM7S but not with LPC2148. With the lat version, I tested started at r1454 I had no success with the STR710 anymore. Therefore I was happy to hear that somebody got the jlink working: https://lists.berlios.de/pipermail/openocd-development/2009-March/005144.htm l It looks that is a general problem with the jlink here. It would be nice if we can go back to a version which is working. For example the version from Jeff (MC1322x). After this I can help to check with my targets here too: STR710, LPC2148, LPC2294, SAM7S, SAM7X, STM32 If the targets are working, we can try tu understand where the problem was and how to optimize the source. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC: tap, ftdi, jlink... what else?
Hello Zach, * J-Link driver (w/ yellow hardware): - cure buggy madness (this is my own poorly qualified TODO item) Does it works on your side? Here I have a jlink too and want to get it working under Mac OS X. And old version, I think 717 was working with e.g. STR710, but the new SVN not anymore. I could start openocd and reset the target, but the GDB do not want to download the program to the CPU. Your yellow one, which version it is? Here I have a v6.0. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC: tap, ftdi, jlink... what else?
Hello Magnus, it looks that the openocd forum will not send mails out in the moment. Just out of curiosity, does the test program run ? It seems strang to load the vector table at 0x21cc . Vector tables are usually placed at the beginning of memory or at an address aligned to a larger power of 2. Yes it works, you can find the source here: http://www.yagarto.de/download/yagarto/STR7Test.zip I have attached the map and d3 log file too. Best regards, Michael test_ram.map Description: Binary data jlink.log Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC: tap, ftdi, jlink... what else?
Hi magnus, Just out of curiosity, does the test program run ? It seems strang to load the vector table at 0x21cc You are right, there is an error in the link file, many thanks. I have not noticed it before, because I use this example to check the toolchain and the debugger. And the example do not work with interrupts. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Added functionality jtag_khz for jlink
Hello, here the function jlink_speed_div was needed to support jtag_khz. Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Patches applied, new version r1462
Hello, the following patches was applied: - openocd-flash-static-keyword-v3.patch - openocd-lpc2000-fix-erase-obo.patch - openocd-jlink-fix-sign-ptr-warn.patch - openocd-wextra-etm.patch - openocd-wextra-jtag.patch - openocd-add-new-tap-symbols-v6.patch Many thanks to Zach Welch. Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Mac OS X (intel) version available (r1461)
Hello List, now I have create a static version of OpenOCD which should run out of the box on Mac OS X. The installer comes with a little readme. You do not need to install additional libraries, the FT2232 driver is include. It was tested on Mac OS X 10.5.6 with a JTAGkey and STR710 target. The OpenOCD version can be found here: http://www.yagarto.de/ Comments welcome. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD: CMake could not find LIBFTDI_LIBRARIES
Hello Dick,
Michael,
Do these changes work for you?
if(NEED_USB)
find_package(LibUSB)
set(CONDITIONAL_LIBS ${CONDITIONAL_LIBS} ${LIBUSB_LIBRARIES})
include_directories( ${LIBUSB_INCLUDE_DIR} )
endif(NEED_USB)
if(BUILD_FT2232_FTD2XX)
#message(BUILD_FT2232_LIBFTDI=\${BUILD_FT2232_LIBFTDI}\)
if(BUILD_FT2232_LIBFTDI)
message( FATAL_ERROR BUILD_FT2232_FTD2XX and BUILD_FT2232_LIBFTDI are
mutually exclusive, please enable only one)
endif(BUILD_FT2232_LIBFTDI)
find_package(LibFTD2XX)
set(CONDITIONAL_LIBS ${LIBFTD2XX_LIBRARIES} ${CONDITIONAL_LIBS})
include_directories( ${LIBFTD2XX_INCLUDE_DIR} )
endif(BUILD_FT2232_FTD2XX)
if(BUILD_FT2232_LIBFTDI)
if(BUILD_FT2232_FTD2XX)
message( FATAL_ERROR BUILD_FT2232_FTD2XX and BUILD_FT2232_LIBFTDI are
mutually exclusive, please enable only one)
endif(BUILD_FT2232_FTD2XX)
find_package(LibFTDI)
set(CONDITIONAL_LIBS ${LIBFTDI_LIBRARIES} ${CONDITIONAL_LIBS})
include_directories( ${LIBFTDI_INCLUDE_DIR} )
endif(BUILD_FT2232_LIBFTDI)
YES, this solved the include problem, but the LIB problem still exist.
Therefore I take a look in the link.txt file where I can find the
linker argument. But here I could not find any references to libusb.a or
libftdi.a.
I think we must add these LIBs too.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD: CMake could not find LIBFTDI_LIBRARIES
Hi Dick,
the LIB problem is a general LIB problem, because the
libusb and libftdi will not be found.
Your line look like:
set(CONDITIONAL_LIBS ${LIBFTDI_LIBRARIES} ${CONDITIONAL_LIBS})
I know that my libs was installed here:
/opt/local/libftdi-0.15
Therefore I changed you like for testing:
set(CONDITIONAL_LIBS /opt/local/libftdi-0.15/lib/libftdi.a
${CONDITIONAL_LIBS})
And now I have no link problems with libftdi. I have done it the
same for libusb, but got now some errors that following symbols
can not be found:
IODestroyPlugInInterface,
CFRunLoopStop
IOMasterPort
and more. All this symbols was referenced in darwin.c
First of all, I think there is a problem with the find_package.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD: CMake could not find LIBFTDI_LIBRARIES
Hello Rick,
When the dylib versions of these are built, they link against
CoreFoundation and IOKit. Since you are using the .a versions, you
need to include the linking against those frameworks. You need to
pass -framework CoreFoundation -framework IOKit to the link line.
It is now woking with your hint and the normal configure. But the CMake
had still the problem not finding the static libs.
In the moment 1:0 for the configure way, my configure looks now:
CFLAGS=-I/opt/local/libftdi-0.15/include -I/opt/local/libusb-0.1.12/include
\
LDFLAGS=-L/opt/local/libftdi-0.15/lib -L/opt/local/libusb-0.1.12/lib \
-framework CoreFoundation -framework IOKit \
./configure --enable-ft2232_libftdi --with-ftd2xx-lib=static
The CMake is working with adding -framework CoreFoundation -framework
IOKit
too. But here the problem still exist to detect the libraries. Here I must
ust the following fix too:
set(CONDITIONAL_LIBS /opt/local/libftdi-0.15/lib/libftdi.a
${CONDITIONAL_LIBS})
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] How to configure the build, without using dynamic libraries?
Hello list, I am working on a Mac OS X installer for OpenOCD. If I only install the openocd executable, I got an error that the dynamic library for libusb and libftdi can not be found. This is correct, because this libraries was not installed. For the toolchain build I could use --disable-shared, or removed the library with the extension dynlib. But how can I get OpenOCD to work without dynamic libraries? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to configure the build, without using dynamic libraries?
Hello Dick, I want to build OpenOCD for FT2232 device, which use later static libraries for libusb and libftdi. This mean that the user do not need to install the libftdi and libusb. Best regards, Michael -Ursprüngliche Nachricht- Von: Dick Hollenbeck [mailto:d...@softplc.com] Gesendet: Dienstag, 14. April 2009 22:00 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] How to configure the build, without using dynamic libraries? Michael Fischer wrote: Hello list, I am working on a Mac OS X installer for OpenOCD. If I only install the openocd executable, I got an error that the dynamic library for libusb and libftdi can not be found. Are you saying that you want to use: 1) static libraries for libusb and libftdi? OR 2) neither static nor dynamic libraries for libusb and libftdi? Which cable driver? Dick This is correct, because this libraries was not installed. For the toolchain build I could use --disable-shared, or removed the library with the extension dynlib. But how can I get OpenOCD to work without dynamic libraries? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to configure the build, without using dynamic libraries?
Hello Dick,
I try to understand how the libftdi test is working, I think
the test source look like (conftest.c):
#include stdio.h
#include ftdi.h
int
main( int argc, char **argv )
{
struct ftdi_context *p;
p = ftdi_new();
if( p != NULL ){
return 0;
} else {
fprintf( stderr, calling ftdi_new() failed\n);
return 1;
}
}
If this can be compiled, the libftdi must be available. Now I try
to make the test by hand.
libftdi is installed here:
/opt/local/libftdi-0.15
and libusb here:
/opt/local/libusb-0.1.12
Therefore I use the following command line:
CFLAGS=-I/opt/local/libftdi-0.15/include -I/opt/local/libusb-0.1.12
LDFLAGS=-L/opt/local/libftdi-0.15/lib -L/opt/local/libusb-0.1.12
LIBS=-lftdi -lusb gcc conftest.c
But got the following error:
Undefined symbols,
_ftdi_new, referenced from:
_main in ccy6Vq7b.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I do not know where the problem is.
Best regards,
Michael
-Ursprüngliche Nachricht-
Von: Dick Hollenbeck [mailto:d...@softplc.com]
Gesendet: Dienstag, 14. April 2009 22:00
An: Michael Fischer
Cc: Openocd-Dev
Betreff: Re: [Openocd-development] How to configure the build, without
using dynamic libraries?
Michael Fischer wrote:
Hello list,
I am working on a Mac OS X installer for OpenOCD.
If I only install the openocd executable, I got an
error that the dynamic library for libusb and libftdi
can not be found.
Are you saying that you want to use:
1) static libraries for libusb and libftdi? OR
2) neither static nor dynamic libraries for libusb and libftdi?
Which cable driver?
Dick
This is correct, because this libraries was not installed.
For the toolchain build I could use --disable-shared, or
removed the library with the extension dynlib.
But how can I get OpenOCD to work without dynamic libraries?
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to configure the build, without using dynamic libraries?
Hello Rick, OpenOCD is already part of MacPorts. But here the user must install MacPorts. Do you know my windows page, www.yagarto.de ? Here the user will find a toolchain, and openocd which works out of the box without to install anything else. For the Mac I want to create a solution like this. The toolchain installer is working, but I have problems with OpenOCD. Best regards, Michael -Ursprungliche Nachricht- Von: Rick Altherr [mailto:kc8...@kc8apf.net] Gesendet: Dienstag, 14. April 2009 22:32 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] How to configure the build, without using dynamic libraries? On Apr 14, 2009, at 11:56 AM, Michael Fischer wrote: Hello list, I am working on a Mac OS X installer for OpenOCD. If I only install the openocd executable, I got an error that the dynamic library for libusb and libftdi can not be found. This is correct, because this libraries was not installed. For the toolchain build I could use --disable-shared, or removed the library with the extension dynlib. But how can I get OpenOCD to work without dynamic libraries? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development OpenOCD is already part of MacPorts. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Could not build r1454 under windows (cygwin), FTDI problems
Hello list, now I am back again and want to start to build the latest version (here r1454) under windows, cygwin. The tools are: - autoconf 2.59 - automake 1.9.6 The ftdi driver is the version: CDM 2.04.16 WHQL Certified For the build, I use the following commands: ./bootstrap ./configure --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/mfischer /openocd/ftd2xx.cdm CC=gcc -mno-cygwin The configure step will produce the following error: checking for ./guess-rev.sh... yes configure: Using: ftdichip.com library: /home/mfischer/openocd/ftd2xx.cdm checking for ftd2xx.lib exists (win32)... checking Test: Build Link with ftd2x x... configure: error: Cannot build run test program using ftd2xx.lib But I have expand the FTDI zip file under /home/mfischer/openocd/ftd2xx.cdm Any ideas? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Could not build r1454 under windows (cygwin), FTDI problems
Hello Thomas, Can you try to copy the ftd2xx.dll to the openocd or windows system directory?! It is not working here, the ftd2xx.dll file can be found under \windows\system32 and inside my openocd build directory, but no success. Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Solved] Could not build r1454 under windows (cygwin), FTDI problems
Hello Thomas, Could you try to run configure without 'CC=gcc -mno-cygwin'? Even the same problem. Or perhaps there's a problem with the . in the directory name? The same problem like with the . Only if I rename the library, I could use the following configure command: ./configure --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/mfischer /openocd/ftd2xx CC=gcc -mno-cygwin Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Please can someone test if GDB and r814 isrunning?
Hello Spen, here is the result from my GDB test: C:\Temp\STR7Testarm-elf-gdb -x .\prj\hitex_str7_ram.gdb test_ram.elf GNU gdb 6.8.50.20080308-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as --host=i686-pc-mingw32 --target=arm-elf... 0x000c115c in ?? () JTAG device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) target state: halted target halted in ARM state due to debug request, current mode: Undefined cpsr: 0x60db pc: 0x000b3240 requesting target halt and executing a soft reset software breakpoints enabled 0xa050: 01c2 Loading section .text, size 0x1cc lma 0x2000 Loading section .vectors, size 0x40 lma 0x21cc Loading section .rodata, size 0x4 lma 0x220c Start address 0x2000, load size 528 Transfer rate: 16 KB/sec, 176 bytes/write. Breakpoint 1 at 0x2170: file src/main.c, line 69. C:\Temp\STR7Test/.\prj\hitex_str7_ram.gdb:15: Error in sourced command file: putpkt: write failed: No error. (gdb) The GDB which I use is 6.8.50-20080308-cvs. With 717 I have no problem here. Even the openocd log and the cfg file is attached. Next I will make a test with the latest trunk. Best regards, Michael -Ursprungliche Nachricht- Von: Spen [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2008 22:22 An: 'Michael Fischer'; 'Openocd-Dev' Betreff: RE: [Openocd-development] Please can someone test if GDB and r814 isrunning? please can someone test if GDB/Insight is working with the trunk 814? Just done a quick test with a luminary target and it seemed ok - including flash programming. One thing i have noticed is that because the resume is no synchronous it does cause an issue. especially if the target resumes and breaks straight away - unsure of a clean way of catching this. I will look into it more tomorrow. Cheers Spen Debug: 6 0 configuration.c:85 find_file(): found ./prj/jtagkey.cfg Debug: 8 0 command.c:412 command_run_line_internal(): telnet_port Debug: 10 0 command.c:412 command_run_line_internal(): gdb_port Debug: 12 0 command.c:412 command_run_line_internal(): gdb_memory_map enable Debug: 14 0 command.c:412 command_run_line_internal(): gdb_flash_program enable Debug: 16 0 command.c:412 command_run_line_internal(): interface ft2232 Debug: 18 0 command.c:412 command_run_line_internal(): ft2232_device_desc Amontec JTAGkey A Debug: 20 0 command.c:412 command_run_line_internal(): ft2232_layout jtagkey Debug: 22 0 command.c:412 command_run_line_internal(): ft2232_vid_pid 0x0403 0xcff8 Debug: 24 0 command.c:412 command_run_line_internal(): jtag_khz 10 16000 Debug: 25 0 jtag.c:1891 handle_jtag_khz_command(): handle jtag khz Info:26 0 options.c:50 configuration_output_handler(): jtag_khz: 10, 16000 Debug: 28 0 command.c:412 command_run_line_internal(): reset_config trst_and_srst srst_pulls_trst Debug: 30 0 command.c:412 command_run_line_internal(): jtag_device 4 0x1 0xf 0xe Debug: 32 0 command.c:412 command_run_line_internal(): daemon_startup reset Info:33 0 options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-07-18-18:27) svn: Debug: 35 0 command.c:412 command_run_line_internal(): target arm7tdmi little run_and_halt 0 arm7tdmi Debug: 37 0 command.c:412 command_run_line_internal(): run_and_halt_time 0 30 Debug: 39 0 command.c:412 command_run_line_internal(): working_area 0 0x2000C000 0x4000 nobackup Debug: 41 0 command.c:412 command_run_line_internal(): flash bank str7x 0x4000 0x0004 0 0 0 STR71x Debug: 43 0 command.c:412 command_run_line_internal(): flash bank str7x 0x400C 0x4000 0 0 0 STR71x Debug: 45 0 command.c:412 command_run_line_internal(): init Debug: 46 0 openocd.c:116 handle_init_command(): target init complete Debug: 47 0 ft2232.c:1374 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'jtagkey' layout (0403:cff8) Debug: 48 16 ft2232.c:1463 ft2232_init_ftd2xx(): current latency timer: 2 Debug: 49 16 ft2232.c:1729 jtagkey_init(): 80 08 1b Debug: 50 16 ft2232.c:1787 jtagkey_init(): 82 09 0f Debug: 51 16 ft2232.c:253 ft2232_speed(): 86 57 02 Debug: 52 31 openocd.c:123 handle_init_command(): jtag interface init complete Debug: 53 31 jtag.c:1542 jtag_init_inner(): Init JTAG chain Debug: 54 31 jtag.c:327 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST) Debug: 55 31 jtag.c:1301 jtag_reset_callback(): - Debug: 56 31 jtag.c:327 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST) Debug: 57 31 jtag.c:1301 jtag_reset_callback(): - Info:58 94 jtag.c:1395 jtag_examine_chain(): JTAG device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) Debug: 59 94
Re: [Openocd-development] Please can someone test if GDB and r814 isrunning?
Hello List, with version 834 the GDB is working again here. Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Please can someone test if GDB and r814 is running?
Hello List, please can someone test if GDB/Insight is working with the trunk 814? I have the feeling that more and more features with the scripting was implemented but no one had test if GDB is still working. It would be a good idea to use a FT2232 device as a reference to check if the debug functionality is still working, please! There are some examples under testing\example. An other problem I have found is that the windows slash \ is still not working anymore in the command line: openocd -f .\prj\jtagkey.cfg is still not working, now the / must be used: openocd -f ./prj/jtagkey.cfg But in this case the auto completion with the tab under windows to complete the path will not work. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problem with r784, runtime error
Hello, the trunk version 784 will not work here with a jtagkey. If I start openocd with: openocd -f .\prj\jtagkey.cfg I got the following error: C:\Temp\LPC2148Testopenocd -f .\prj\jtagkey.cfg Open On-Chip Debugger 1.0 (2008-07-10-19:08) svn: $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ Info:options.c:50 configuration_output_handler(): Runtime error, file ?, l ine 1: Info:options.c:50 configuration_output_handler(): invalid command name script Even if I try to start with debug like: C:\Temp\LPC2148Testopenocd -f .\prj\jtagkey.cfg -d3 -ltest.txt Open On-Chip Debugger 1.0 (2008-07-10-19:08) svn: $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ Info:options.c:50 configuration_output_handler(): Runtime error, file ?, l ine 1: Info:options.c:50 configuration_output_handler(): invalid command name debug_level Info:options.c:50 configuration_output_handler(): Runtime error, file ?, l ine 1: Info:options.c:50 configuration_output_handler(): invalid command name log_output Info:options.c:50 configuration_output_handler(): Runtime error, file ?, l ine 1: Info:options.c:50 configuration_output_handler(): invalid command name script Attached you will find my cfg file too. Best regards, Michael jtagkey.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Is tcl now a must have?
Hello, with the trunk 785 I got the following error message: C:\Temp\LPC2148Testopenocd -f .\prj\jtagkey.cfg Open On-Chip Debugger 1.0 (2008-07-10-20:47) svn: $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ Error: openocd.c:577 initJim2(): Can not find tcl/commands.tcl - check install ation I could imagine that there was a note that the scripting makes only sense for the developers and not the normal users. But now it looks that the tcl feature and directories must installed too. In this case it will break the older functionality before the script feature was added. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
