Re: [Openocd-development] [PATCH] CMake Support
I am not very keen on changing anything in terms of tools around openocd as there are a lot of developers out there that are familiar with the current situation. Every so often we get a request to use some new tool, switch version control, etc. I believe that it is a good thing that any such switch must be consensus made and that the rate of switching introducing new tools is low so as not to alienate the occasional participants. Also, I think OpenOCD is the wrong project to help test promote some great, but off the beaten path, tool/method. Better the devil you know. What's the advantage of switching if everything works fine now? -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Cmake part 2
Here is another grazy idea regarding build tools: how about adding Eclipse project definitions? From experience I know that Eclipse projects can be transferred between Windows and Linux without problems. I agree the autotools aren't ideal especially when cross-compiling. When cross compiling software the biggest problem usually is getting the configure script to work right. A lot of programmers seem to completely forget about cross compiling at all. Even openocd doesn't cross compile out of the box. -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Dick Hollenbeck Verzonden: dinsdag 14 april 2009 14:02 Aan: Openocd-Dev Onderwerp: [Openocd-development] [PATCH] Cmake part 2 This adds config.h.cmake which was missing in the first patch. It seems that I will need help getting this committed. CMake fans please step forward and make your voices heard. CMake has been accused of being off the beaten path. From my perspective, those that take the autotools path are the ones being beaten. It is not a problem to support two build tools for an indefinite period in time. The space in the repository is free. Dick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Cmake part 2
This adds config.h.cmake which was missing in the first patch. It seems that I will need help getting this committed. CMake fans please step forward and make your voices heard. CMake has been accused of being off the beaten path. From my perspective, those that take the autotools path are the ones being beaten. It is not a problem to support two build tools for an indefinite period in time. The space in the repository is free. Dick Index: src/config.h.cmake === --- src/config.h.cmake (revision 0) +++ src/config.h.cmake (revision 0) @@ -0,0 +1,197 @@ +/*** + * Copyright (C) 2009 SoftPLC Corporation http://softplc.com * + * Dick Hollenbeck d...@softplc.com* + * * + * This program is free software; you can redistribute it and/or modify * + * it under the terms of the GNU General Public License as published by * + * the Free Software Foundation; either version 2 of the License, or * + * (at your option) any later version. * + * * + * This program is distributed in the hope that it will be useful, * + * but WITHOUT ANY WARRANTY; without even the implied warranty of* + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * + * GNU General Public License for more details. * + * * + * You should have received a copy of the GNU General Public License * + * along with this program; if not, write to the * + * Free Software Foundation, Inc., * + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * + ***/ + +/* config.h is created by CMake during a preprocessing operation from config.h.cmake */ + +/* if you want the Amontec JTAG-Accelerator driver. */ +#cmakedefine BUILD_AMTJTAGACCEL 1 + +/* if you want the ARM-JTAG-EW JTAG driver. */ +#cmakedefine BUILD_ARMJTAGEW 1 + +/* if you want at91rm9200. */ +#cmakedefine BUILD_AT91RM9200 1 + +/* if you want a bitbang interface. */ +#cmakedefine BUILD_BITBANG 1 + +/* if you want a bitq interface. */ +#cmakedefine BUILD_BITQ 1 + +/* if you want dummy driver. */ +#cmakedefine BUILD_DUMMY 1 + +/* if you want eCosBoard. */ +#cmakedefine BUILD_ECOSBOARD 1 + +/* if you want ep93xx. */ +#cmakedefine BUILD_EP93XX 1 + +/* if you want ftd2xx ft2232. */ +#cmakedefine BUILD_FT2232_FTD2XX 1 + +/* if you want libftdi ft2232. */ +#cmakedefine BUILD_FT2232_LIBFTDI 1 + +/* if you want the Gateworks GW16012 driver. */ +#cmakedefine BUILD_GW16012 1 + +/* if you want httpd. */ +#cmakedefine BUILD_HTTPD 1 + +/* if you want ioutils. */ +#cmakedefine BUILD_IOUTIL 1 + +/* if you want the J-Link JTAG driver. */ +#cmakedefine BUILD_JLINK 1 + +/* if you want the OpenOCD+trace ETM capture driver. */ +#cmakedefine BUILD_OOCD_TRACE 1 + +/* if you want parport. */ +#cmakedefine BUILD_PARPORT 1 + +/* if you want the ASIX PRESTO driver using FTD2XX. */ +#cmakedefine BUILD_PRESTO_FTD2XX 1 + +/* if you want the ASIX PRESTO driver using libftdi. */ +#cmakedefine BUILD_PRESTO_LIBFTDI 1 + +/* if you want the RLink JTAG driver. */ +#cmakedefine BUILD_RLINK 1 + +/* if you want the usbprog JTAG driver. */ +#cmakedefine BUILD_USBPROG 1 + +/* if you want the Versaloon-Link JTAG driver. */ +#cmakedefine BUILD_VSLLINK 1 + +/* if you want parport to use giveio. */ +#cmakedefine PARPORT_USE_GIVEIO 1 + +/* if you want parport to use ppdev. */ +#cmakedefine PARPORT_USE_PPDEV 1 + +/* Define to 1 if you have the elf.h header file. */ +#cmakedefine HAVE_ELF_H 1 + +/* Define to 1 if you have the `gettimeofday' function. */ +#cmakedefine HAVE_GETTIMEOFDAY 1 + +/* Define to 1 if you have the inttypes.h header file. */ +#cmakedefine HAVE_INTTYPES_H 1 + +/* Define to 1 if you have the jtag_minidriver.h header file. */ +#cmakedefine HAVE_JTAG_MINIDRIVER_H 1 + +/* Define to 1 if you have the memory.h header file. */ +#cmakedefine HAVE_MEMORY_H 1 + +/* Define to 1 if you have the stdbool.h header file. */ +#cmakedefine HAVE_STDBOOL_H 1 + +/* Define to 1 if you have the stdint.h header file. */ +#cmakedefine HAVE_STDINT_H 1 + +/* Define to 1 if you have the stdlib.h header file. */ +#cmakedefine HAVE_STDLIB_H 1 + +/* Define to 1 if you have the strings.h header file. */ +#cmakedefine HAVE_STRINGS_H 1 + +/* Define to 1 if you have the string.h header file. */ +#cmakedefine HAVE_STRING_H 1 + +/* Define to 1 if you have the `strndup' function. */ +#cmakedefine HAVE_STRNDUP 1 + +/* Define to 1 if you have the `strnlen' function.
Re: [Openocd-development] [PATCH] CMake Support
Øyvind Harboe wrote: I am not very keen on changing anything in terms of tools around openocd as there are a lot of developers out there that are familiar with the current situation. Every so often we get a request to use some new tool, switch version control, etc. I believe that it is a good thing that any such switch must be consensus made and that the rate of switching introducing new tools is low so as not to alienate the occasional participants. Also, I think OpenOCD is the wrong project to help test promote some great, but off the beaten path, tool/method. Better the devil you know. What's the advantage of switching if everything works fine now? Øyvind, Here is a start: http://lwn.net/Articles/188693/ http://www.cmake.org/cmake/project/about.html The best thing is to try it on linux. I can walk you through that, and as we were to do that it would be good to develop a HOWTO text file for new users that records the right turns and warns of the wrong turns during the process.We have something like that for Kicad, where I am one of the main developers: http://kicad.svn.sourceforge.net/viewvc/kicad/trunk/kicad/COMPILING.txt?revision=1472view=markup HTH, Dick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] CMake Support
Kishore,
Thank you for your efforts to make this usable by those who would.
Attached is a single comprehensive patch, which should be used instead
of my two previous patches.
For those who would like to give it a spin, remember to use an out of
source build, and to use the ccmake command to refine your
configuration options after you have run cmake once. You do not need to
get every configure option correct on the first pass. After that first
pass, ccmake instead of cmake can be used. ccmake has a gui, and there
are variations of this program for windows.
Dick
Index: src/helper/CMakeLists.txt
===
--- src/helper/CMakeLists.txt (revision 0)
+++ src/helper/CMakeLists.txt (revision 0)
@@ -0,0 +1,43 @@
+# Copyright 2009 SoftPLC Corporation http://softplc.com
+# Dick Hollenbeck d...@softplc.com
+# License: GPL v2
+
+
+
+add_executable(bin2char bin2char.c)
+add_custom_command(
+OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/startup_tcl.c
+COMMAND bin2char startup_tcl ${CMAKE_CURRENT_SOURCE_DIR}/startup.tcl ${CMAKE_CURRENT_BINARY_DIR}/startup_tcl.c
+DEPENDS bin2char ${CMAKE_CURRENT_SOURCE_DIR}/startup.tcl
+)
+
+
+set( HELPER_SRCS
+ binarybuffer.c
+ command.c
+ configuration.c
+ fileio.c
+ log.c
+ replacements.c
+ ${CMAKE_CURRENT_BINARY_DIR}/startup_tcl.c
+ time_support.c
+)
+
+
+if(NOT BUILD_ECOSBOARD)
+
+# omit these sources if building ecosboard, otherwise include them
+set( HELPER_SRCS ${HELPER_SRCS} options.c jim.c jim-eventloop.c )
+
+endif(NOT BUILD_ECOSBOARD)
+
+
+if(BUILD_IOUTIL)
+
+# add these souces if BUILD_IOUTIL
+set( HELPER_SRCS ${HELPER_SRCS} ioutil.c )
+
+endif(BUILD_IOUTIL)
+
+
+add_library(helper STATIC ${HELPER_SRCS})
Property changes on: src/helper/CMakeLists.txt
___
Added: svn:mime-type
+ text/plain
Added: svn:eol-style
+ native
Index: src/pld/CMakeLists.txt
===
--- src/pld/CMakeLists.txt (revision 0)
+++ src/pld/CMakeLists.txt (revision 0)
@@ -0,0 +1,11 @@
+# Copyright 2009 SoftPLC Corporation http://softplc.com
+# Dick Hollenbeck d...@softplc.com
+# License: GPL v2
+
+SET(PLD_SRCS
+ pld.c
+ xilinx_bit.c
+ virtex2.c
+)
+
+add_library(pld STATIC ${PLD_SRCS})
Property changes on: src/pld/CMakeLists.txt
___
Added: svn:mime-type
+ text/plain
Added: svn:eol-style
+ native
Index: src/jtag/CMakeLists.txt
===
--- src/jtag/CMakeLists.txt (revision 0)
+++ src/jtag/CMakeLists.txt (revision 0)
@@ -0,0 +1,78 @@
+# Copyright 2009 SoftPLC Corporation http://softplc.com
+# Dick Hollenbeck d...@softplc.com
+# License: GPL v2
+
+
+include_directories(
+${CMAKE_CURRENT_SOURCE_DIR}/rlink
+)
+
+set(JTAG_SRCS jtag.c)
+
+
+if(BUILD_BITBANG OR BUILD_DUMMY OR BUILD_EP93XX OR BUILD_ECOSBOARD OR BUILD_PARPORT OR BUILD_AT91RM9200)
+list(APPEND JTAG_SRCS bitbang.c)
+endif(BUILD_BITBANG OR BUILD_DUMMY OR BUILD_EP93XX OR BUILD_ECOSBOARD OR BUILD_PARPORT OR BUILD_AT91RM9200)
+
+if(BUILD_PARPORT)
+list(APPEND JTAG_SRCS parport.c)
+endif(BUILD_PARPORT)
+
+if(BUILD_DUMMY)
+list(APPEND JTAG_SRCS dummy.c)
+endif(BUILD_DUMMY)
+
+if(BUILD_FT2232_FTD2XX OR BUILD_FT2232_LIBFTDI)
+list(APPEND JTAG_SRCS ft2232.c)
+endif(BUILD_FT2232_FTD2XX OR BUILD_FT2232_LIBFTDI)
+
+if(BUILD_AMTJTAGACCEL)
+list(APPEND JTAG_SRCS amt_jtagaccel.c)
+endif(BUILD_AMTJTAGACCEL)
+
+if(BUILD_EP93XX)
+list(APPEND JTAG_SRCS ep93xx.c)
+endif(BUILD_EP93XX)
+
+if(BUILD_AT91RM9200)
+list(APPEND JTAG_SRCS at91rm9200.c)
+endif(BUILD_AT91RM9200)
+
+if(BUILD_GW16012)
+list(APPEND JTAG_SRCS gw16012.c)
+endif(BUILD_GW16012)
+
+if(BUILD_BITQ)
+list(APPEND JTAG_SRCS bitq.c)
+endif(BUILD_BITQ)
+
+if(BUILD_PRESTO)
+list(APPEND JTAG_SRCS presto.c)
+endif(BUILD_PRESTO)
+
+if(BUILD_USBPROG)
+list(APPEND JTAG_SRCS usbprog.c)
+endif(BUILD_USBPROG)
+
+if(BUILD_ECOSBOARD)
+list(APPEND JTAG_SRCS zy1000.c)
+endif(BUILD_ECOSBOARD)
+
+if(BUILD_JLINK)
+list(APPEND JTAG_SRCS jlink.c)
+endif(BUILD_JLINK)
+
+if(BUILD_RLINK)
+list(APPEND JTAG_SRCS rlink/rlink.c rlink/rlink_speed_table.c)
+endif(BUILD_RLINK)
+
+if(BUILD_VSLLINK)
+list(APPEND JTAG_SRCS vsllink.c)
+endif(BUILD_VSLLINK)
+
+if(BUILD_ARM_JTAG_EW)
+list(APPEND JTAG_SRCS arm-jtag-ew.c)
+endif(BUILD_ARM_JTAG_EW)
+
+
+add_library(jtag STATIC ${JTAG_SRCS})
Property changes on: src/jtag/CMakeLists.txt
___
Added: svn:mime-type
+ text/plain
Added: svn:eol-style
+ native
Index: src/target/CMakeLists.txt
===
--- src/target/CMakeLists.txt (revision 0)
+++ src/target/CMakeLists.txt (revision 0)
@@ -0,0 +1,74 @@
+# Copyright 2009 SoftPLC
[Openocd-development] Keil AGDI interface to openOCD?
Dear people, I am looking for a way to use keil uvision with openOCD; I found that keil has an API to talk to third party debuggers, but I can not find a driver to talk to openOCD. So, is there any imposibility to do that, or just nobody wrote it yet? Thanks in advance for your help. best regards, Pedro Ignacio Martos pmar...@fi.uba.ar http://www.fi.uba.ar/~pmartos/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Beginners help with OpenOCD, STM3210E-EVAL and Olimex ARM-USB-TINY JTAG connector.
Hello, I'm new to embedded development and I've just bought a STM3210E-EVAL board and an Olimex ARM-USB-TINY JTAG connector to play with. I've managed to set the tool chain and such up and I'm having trouble flashing an application. The application is from the ST example code and blinks the LEDs on and off. I've compiled an example program as follows: arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -T generic-m.ld -I /home/taylorr/Desktop/um0427/Libraries/STM32F10x_StdPeriph_Driver/inc -I /home/taylorr/Desktop/um0427/Libraries/CMSIS/Core/CM3 /home/taylorr/Desktop/um0427/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_gpio.c /home/taylorr/Desktop/um0427/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_rcc.c /home/taylorr/Desktop/um0427/Libraries/CMSIS/Core/CM3/system_stm32f10x.c stm32f10x_it.c main.c -o hello I used objcopy as follows: arm-none-eabi-objcopy -j .text a.out hello.bin -O binary Which produces the following file: -rwxr-xr-x 1 taylorr taylorr 6156 2009-04-09 14:35 hello.bin I started OpenOCD as follows: C:\Documents and Settings\Robert Taylor\Desktopopenocd -d 3 -l openocd.log -s C:\Program Files\OpenOCD\0.1.0 -f interface\olimex-jtag-tiny-a.cfg -f board\stm3210e_eval.cfg Open On-Chip Debugger 0.1.0 (2009-01-21-21:15) Release BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src /openocd.c $ User : 5 16 command.c:494 command_run_line(): Debug: 7 16 command.c:91 script_command(): script_command - log_output Debug: 8 16 command.c:108 script_command(): script_command - log_output, argv[0]=ocd_log_output Debug: 9 16 command.c:108 script_command(): script_command - log_output, argv[1]=openocd.log I used Telnet to talk to the board as follows: Open On-Chip Debugger halt target was in unknown state when halt was requested stm32x unlock 0 device id = 0x10016414 flash size = 512kbytes stm32x unlocked flash erase_sector 0 0 0 erased sectors 0 through 0 on flash bank 0 in 0.062500s flash write_bank 0 C:/Documents and Settings/Robert Taylor/Desktop/hello.bin 0 flash writing failed with error code: 0xfc7a error writing to flash at address 0x0800 at offset 0x (-902) called at file command.c, line 456 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 The OpenOCD log has the following information: User : 10 16 command.c:494 command_run_line(): Debug: 11 16 configuration.c:88 find_file(): found C:\Program Files\OpenOCD\0.1.0\bin\../interface\olimex-jtag-tiny-a.cfg Debug: 13 16 command.c:91 script_command(): script_command - interface Debug: 14 16 command.c:108 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 15 16 command.c:108 script_command(): script_command - interface, argv[1]=ft2232 Debug: 17 16 command.c:91 script_command(): script_command - ft2232_device_desc Debug: 18 16 command.c:108 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 19 16 command.c:108 script_command(): script_command - ft2232_device_desc, argv[1]=Olimex OpenOCD JTAG TINY A Debug: 21 16 command.c:91 script_command(): script_command - ft2232_layout Debug: 22 16 command.c:108 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout Debug: 23 16 command.c:108 script_command(): script_command - ft2232_layout, argv[1]=olimex-jtag User : 24 16 command.c:494 command_run_line(): Debug: 25 16 configuration.c:88 find_file(): found C:\Program Files\OpenOCD\0.1.0\bin\../board\stm3210e_eval.cfg Debug: 26 16 configuration.c:88 find_file(): found C:\Program Files\OpenOCD\0.1.0\bin\../target/stm32.cfg Debug: 28 16 command.c:91 script_command(): script_command - jtag_khz Debug: 29 16 command.c:108 script_command(): script_command - jtag_khz, argv[0]=ocd_jtag_khz Debug: 30 16 command.c:108 script_command(): script_command - jtag_khz, argv[1]=500 Debug: 31 16 jtag.c:2645 handle_jtag_khz_command(): handle jtag khz User : 32 16 command.c:383 command_print(): 500 kHz Debug: 34 16 command.c:91 script_command(): script_command - jtag_nsrst_delay Debug: 35 16 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[0]=ocd_jtag_nsrst_delay Debug: 36 16 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[1]=100 Debug: 38 16 command.c:91 script_command(): script_command - jtag_ntrst_delay Debug: 39 16 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[0]=ocd_jtag_ntrst_delay Debug: 40 16 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[1]=100 Debug: 42 16 command.c:91 script_command(): script_command - reset_config Debug: 43 16 command.c:108 script_command(): script_command - reset_config, argv[0]=ocd_reset_config Debug: 44 16 command.c:108 script_command(): script_command - reset_config, argv[1]=trst_and_srst Debug: 45 16 jtag.c:1892 jim_newtap_cmd(): Creating New Tap, Chip: stm32, Tap: cpu, Dotted: stm32.cpu, 8 params Debug:
Re: [Openocd-development] Beginners help with OpenOCD, STM3210E-EVAL and Olimex ARM-USB-TINY JTAG connector.
Instead of all the commands you use, just do 'reset halt' and then flash write_image erase file_name.extension 0 bin 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Segfault when using breakpoints
Hi, The patch does not have any side effects and problem seems to be solved so I have committed the patch with minor cosmetic changes. Thanks. Regards, Magnus Zach Welch wrote: Given your information and the code, the attached patch should work around the problem, unless there are instructions not handled by the following block of logic. I added output to see if that is the case. Cheers, Zach On Tue, 2009-04-14 at 00:50 +0200, Magnus Lundin wrote: Hi, Is it possible to find out the exact assembly code that kills OpenOCD ? Let me guess that I could be an immediate shift or MOVS in thumb mode . I am not an expert on the single step PC prediction code in arm_simulate_step(target_t *target, u32 *dry_run_pc) but there are some tumb instructions that does not have an Rn argument. See arm_dissassembler.c:1444 in evaluate_shift_imm_thumb(u16 opcode, u32 address, arm_instruction_t *instruction) This will give a value of -1 for the register number instruction.info.data_proc.Rn at line 418 in arm_simulator.c . Regards, Magnus Ken Smith wrote: On Mon, Apr 13, 2009 at 2:23 PM, Hermann Kraus h...@scribus.info wrote: On Mon, 13 Apr 2009 23:11:29 +0200, Ken Smith kgsm...@gmail.com wrote: This crash kills openocd every time. Any ideas? I have the same problem and one more person on this list also reported it. It crashes at exactly the same location. I hope someone fixes this soon, as I currently don't have the time to debug this problem. Here's the thread where I reported the problem: https://lists.berlios.de/pipermail/openocd-development/2009-April/005257.html Sorry for the duplication. I'm also keenly interested in a fix to this. Is anyone out there working on this? (assume: usual disclaimers about FOSS) Many thanks for the quick response. Warm regards, Ken ___ 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Beginners help with OpenOCD, STM3210E-EVAL and Olimex ARM-USB-TINY JTAG connector.
Hi You are just erasing one sector of the flash memory, 1k, and probalby your bin file is larger. Try something like: flash erase_sector 0 0 10 Magnus Robert Taylor wrote: Hello, I'm new to embedded development and I've just bought a STM3210E-EVAL board and an Olimex ARM-USB-TINY JTAG connector to play with. I've managed to set the tool chain and such up and I'm having trouble flashing an application. The application is from the ST example code and blinks the LEDs on and off. I've compiled an example program as follows: arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -T generic-m.ld -I /home/taylorr/Desktop/um0427/Libraries/STM32F10x_StdPeriph_Driver/inc -I /home/taylorr/Desktop/um0427/Libraries/CMSIS/Core/CM3 /home/taylorr/Desktop/um0427/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_gpio.c /home/taylorr/Desktop/um0427/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_rcc.c /home/taylorr/Desktop/um0427/Libraries/CMSIS/Core/CM3/system_stm32f10x.c stm32f10x_it.c main.c -o hello I used objcopy as follows: arm-none-eabi-objcopy -j .text a.out hello.bin -O binary Which produces the following file: -rwxr-xr-x 1 taylorr taylorr 6156 2009-04-09 14:35 hello.bin I started OpenOCD as follows: C:\Documents and Settings\Robert Taylor\Desktopopenocd -d 3 -l openocd.log -s C:\Program Files\OpenOCD\0.1.0 -f interface\olimex-jtag-tiny-a.cfg -f board\stm3210e_eval.cfg Open On-Chip Debugger 0.1.0 (2009-01-21-21:15) Release BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src /openocd.c $ User : 5 16 command.c:494 command_run_line(): Debug: 7 16 command.c:91 script_command(): script_command - log_output Debug: 8 16 command.c:108 script_command(): script_command - log_output, argv[0]=ocd_log_output Debug: 9 16 command.c:108 script_command(): script_command - log_output, argv[1]=openocd.log I used Telnet to talk to the board as follows: Open On-Chip Debugger halt target was in unknown state when halt was requested stm32x unlock 0 device id = 0x10016414 flash size = 512kbytes stm32x unlocked flash erase_sector 0 0 0 erased sectors 0 through 0 on flash bank 0 in 0.062500s flash write_bank 0 C:/Documents and Settings/Robert Taylor/Desktop/hello.bin 0 flash writing failed with error code: 0xfc7a error writing to flash at address 0x0800 at offset 0x (-902) called at file command.c, line 456 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 The OpenOCD log has the following information: User : 10 16 command.c:494 command_run_line(): Debug: 11 16 configuration.c:88 find_file(): found C:\Program Files\OpenOCD\0.1.0\bin\../interface\olimex-jtag-tiny-a.cfg Debug: 13 16 command.c:91 script_command(): script_command - interface Debug: 14 16 command.c:108 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 15 16 command.c:108 script_command(): script_command - interface, argv[1]=ft2232 Debug: 17 16 command.c:91 script_command(): script_command - ft2232_device_desc Debug: 18 16 command.c:108 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 19 16 command.c:108 script_command(): script_command - ft2232_device_desc, argv[1]=Olimex OpenOCD JTAG TINY A Debug: 21 16 command.c:91 script_command(): script_command - ft2232_layout Debug: 22 16 command.c:108 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout Debug: 23 16 command.c:108 script_command(): script_command - ft2232_layout, argv[1]=olimex-jtag User : 24 16 command.c:494 command_run_line(): Debug: 25 16 configuration.c:88 find_file(): found C:\Program Files\OpenOCD\0.1.0\bin\../board\stm3210e_eval.cfg Debug: 26 16 configuration.c:88 find_file(): found C:\Program Files\OpenOCD\0.1.0\bin\../target/stm32.cfg Debug: 28 16 command.c:91 script_command(): script_command - jtag_khz Debug: 29 16 command.c:108 script_command(): script_command - jtag_khz, argv[0]=ocd_jtag_khz Debug: 30 16 command.c:108 script_command(): script_command - jtag_khz, argv[1]=500 Debug: 31 16 jtag.c:2645 handle_jtag_khz_command(): handle jtag khz User : 32 16 command.c:383 command_print(): 500 kHz Debug: 34 16 command.c:91 script_command(): script_command - jtag_nsrst_delay Debug: 35 16 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[0]=ocd_jtag_nsrst_delay Debug: 36 16 command.c:108 script_command(): script_command - jtag_nsrst_delay, argv[1]=100 Debug: 38 16 command.c:91 script_command(): script_command - jtag_ntrst_delay Debug: 39 16 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[0]=ocd_jtag_ntrst_delay Debug: 40 16 command.c:108 script_command(): script_command - jtag_ntrst_delay, argv[1]=100 Debug: 42 16 command.c:91 script_command(): script_command - reset_config
[Openocd-development] Error reporting in flash modules.
Hi I have commited a patch that gives more readable error reporting for STM32 flash writing errors. But still all errors are reported with the error code ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not very helpul about the cause of the error. My suggestion is to return the more differentiated error codes already available in flash.h without so many verbose messages and then generate meaningful LOG_ERROR text messages in flash.c . ? Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink vrs ft2232 tap transitions - some differences.
Dick Hollenbeck wrote: Duane Ellis wrote: Dick I am working on the ft232 stuff starting today. I am to - we should coordinate... my changes are non-trivial. -Duane. OK, send me what you have and what your thought are to Personal Mail if you want. Until I get that, I have some stuff to do on xsvf.c and am looking at adding support for CMake. Dick Hello Duane, What's up with this? This is now in my critical path. I would like to get your non-trivial changes ASAP. I am all over this this PM. Thanks, Dick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] xsvf patch
Johann F. wrote: I can't make out the important changes from the gratuitous ones. Can you please revert all the u8 - uint8_t changes as well as whitespace changes? -- Rick Altherr kc8...@kc8apf.net Its been a week now. I can boil it down and find the essence of the changes. I was going to get back to this code in the next couple of weeks anyway. There could be some useful changes in this mess. If they are there, I will find them. Dick There are my changes again. I noticed that i forget to handle runtest_requires_tck in new function xs_shift. Johann Johann, I am feeling no love for this patch. I do not see where any flow is different than the original code, other than you are multiplying xruntest by 16 on successive attempts. This multiply by 16 is not part of the Xylinx docs or algorithm for the intended chip, let alone any other FPGA or arbitrary SVF recipient. This xruntest value can be set to a higher number in your toolset which generates the xsvf file? I'll give it another look, I have an FPGA to program here. Maybe I am missing something in the patch, but I went over it line by line. And yes, we lost the runtest_requires_tck support in your patch also. In the next several days, I will try my fpga hardware and see if there is any general problem persisting. Troubleshooting things like this are made far easier by my new tap_set_state() logging functionality. However, there are still tap state transitions that are not being logged, and I think this is a needed enhancement that I would like to correct as soon as I have time to. All state transitions should go through tap_set_state(). When logging is turned off, there is no perceptible overhead, since it is a compile time off/on option. Dick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] xsvf.c
This patch adds a couple of lines from Johann's patch, but mostly it is
merely a matter of left indenting the big switch statement by one tab
stop.
Since the function is big, and indentation levels are used liberally, I
felt we needed to scoot left one tab stop. This is consistent with the
uncrustify.cfg's handling of switch(), although I did not run
uncrustify against this source file.
Please commit, so we can go forward from here together.
Thanks,
Dick
Index: src/xsvf/xsvf.c
===
--- src/xsvf/xsvf.c (revision 1456)
+++ src/xsvf/xsvf.c (working copy)
@@ -9,7 +9,7 @@
* peter.hettk...@htp-tel.de *
* *
* Copyright (C) 2009 SoftPLC Corporation. http://softplc.com *
- * d...@softplc.com *
+ * Dick Hollenbeck d...@softplc.com *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -352,659 +352,652 @@
switch (opcode)
{
- case XCOMPLETE:
-LOG_DEBUG(XCOMPLETE);
+ case XCOMPLETE:
+ LOG_DEBUG(XCOMPLETE);
-result = jtag_execute_queue();
-if (result != ERROR_OK)
-{
- tdo_mismatch = 1;
- break;
-}
+ result = jtag_execute_queue();
+ if (result != ERROR_OK)
+ {
+tdo_mismatch = 1;
break;
+ }
+ break;
- case XTDOMASK:
-LOG_DEBUG(XTDOMASK);
-if (dr_in_mask (xsvf_read_buffer(xsdrsize, xsvf_fd, dr_in_mask) != ERROR_OK))
- do_abort = 1;
-break;
+ case XTDOMASK:
+ LOG_DEBUG(XTDOMASK);
+ if (dr_in_mask (xsvf_read_buffer(xsdrsize, xsvf_fd, dr_in_mask) != ERROR_OK))
+do_abort = 1;
+ break;
- case XRUNTEST:
+ case XRUNTEST:
+ {
+u8 xruntest_buf[4];
+
+if (read(xsvf_fd, xruntest_buf, 4) 0)
{
- u8 xruntest_buf[4];
+ do_abort = 1;
+ break;
+}
- if (read(xsvf_fd, xruntest_buf, 4) 0)
- {
- do_abort = 1;
- break;
- }
+xruntest = be_to_h_u32(xruntest_buf);
+LOG_DEBUG(XRUNTEST %d 0x%08X, xruntest, xruntest);
+ }
+ break;
- xruntest = be_to_h_u32(xruntest_buf);
- LOG_DEBUG(XRUNTEST %d 0x%08X, xruntest, xruntest);
-}
-break;
+ case XREPEAT:
+ {
+u8 myrepeat;
- case XREPEAT:
+if (read(xsvf_fd, myrepeat, 1) 0)
+ do_abort = 1;
+else
{
- u8 myrepeat;
-
- if (read(xsvf_fd, myrepeat, 1) 0)
- do_abort = 1;
- else
- {
- xrepeat = myrepeat;
- LOG_DEBUG(XREPEAT %d, xrepeat );
- }
+ xrepeat = myrepeat;
+ LOG_DEBUG(XREPEAT %d, xrepeat );
}
-break;
+ }
+ break;
- case XSDRSIZE:
+ case XSDRSIZE:
+ {
+u8 xsdrsize_buf[4];
+
+if (read(xsvf_fd, xsdrsize_buf, 4) 0)
{
- u8 xsdrsize_buf[4];
+ do_abort = 1;
+ break;
+}
- if (read(xsvf_fd, xsdrsize_buf, 4) 0)
- {
- do_abort = 1;
- break;
- }
+xsdrsize = be_to_h_u32(xsdrsize_buf);
+LOG_DEBUG(XSDRSIZE %d, xsdrsize);
- xsdrsize = be_to_h_u32(xsdrsize_buf);
- LOG_DEBUG(XSDRSIZE %d, xsdrsize);
+if( dr_out_buf ) free(dr_out_buf);
+if( dr_in_buf) free(dr_in_buf);
+if( dr_in_mask) free(dr_in_mask);
- if( dr_out_buf ) free(dr_out_buf);
- if( dr_in_buf) free(dr_in_buf);
- if( dr_in_mask) free(dr_in_mask);
+dr_out_buf = malloc((xsdrsize + 7) / 8);
+dr_in_buf = malloc((xsdrsize + 7) / 8);
+dr_in_mask = malloc((xsdrsize + 7) / 8);
+ }
+ break;
- dr_out_buf = malloc((xsdrsize + 7) / 8);
- dr_in_buf = malloc((xsdrsize + 7) / 8);
- dr_in_mask = malloc((xsdrsize + 7) / 8);
-}
-break;
+ case XSDR: /* these two are identical except for the dr_in_buf */
+ case XSDRTDO:
+ {
+int limit = xrepeat;
+int matched = 0;
+int attempt;
- case XSDR: /* these two are identical except for the dr_in_buf */
- case XSDRTDO:
+const char* op_name = (opcode == XSDR ? XSDR : XSDRTDO);
+
+if (xsvf_read_buffer(xsdrsize, xsvf_fd, dr_out_buf) != ERROR_OK)
{
- int limit = xrepeat;
- int matched = 0;
- int attempt;
+ do_abort = 1;
+ break;
+}
- const char* op_name = (opcode == XSDR ? XSDR : XSDRTDO);
-
- if (xsvf_read_buffer(xsdrsize, xsvf_fd, dr_out_buf) != ERROR_OK)
+if (opcode == XSDRTDO)
+{
+ if(xsvf_read_buffer(xsdrsize, xsvf_fd, dr_in_buf) != ERROR_OK )
{
do_abort = 1;
break;
}
+}
- if (opcode == XSDRTDO)
- {
- if(xsvf_read_buffer(xsdrsize, xsvf_fd, dr_in_buf) != ERROR_OK )
- {
- do_abort = 1;
- break;
- }
- }
+if (limit 1)
+ limit = 1;
- if (limit 1)
- limit = 1;
+LOG_DEBUG(%s %d, op_name, xsdrsize);
- LOG_DEBUG(%s %d, op_name, xsdrsize);
+for( attempt=0; attemptlimit; ++attempt )
+{
+
Re: [Openocd-development] Error reporting in flash modules.
On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Hi I have commited a patch that gives more readable error reporting for STM32 flash writing errors. But still all errors are reported with the error code ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not very helpul about the cause of the error. My suggestion is to return the more differentiated error codes already available in flash.h without so many verbose messages and then generate meaningful LOG_ERROR text messages in flash.c . ? I'd rather go the other way, not to try to communicate any information through error codes, i.e. to use it *only* as a boolean fail/success. There are only a few places in which the error codes are checked, and I see little reason to expose error codes to the user. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to go on with Cortex-A8 support
Hi
The following patch is a first step towards support for sevaral AP in
one dap.
- Adds a apsel variable, corresponding to the corresponding field in the
DP SELECT register, to the swjdap structure.
- adds a function swjdp_apselect(swjdp_common_t *swjdp,u8 apsel) to set
this variable.
- adds two cortex_m3 interactive commands
cortex_m3 dap #n Shows the contents of ROM/Debug base register
and AP ID Register
cortex_m3 apsel #nConfigures to use AP #n in subsequent memory
accesses.
This should be a possible starting point to explore other debug
configurations that the Cortex_M3
Tested on STM32 with no problems found. I dont have any A8 hardware.
Regards,
Magnus
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 1454)
+++ src/target/cortex_m3.c (working copy)
@@ -45,6 +45,8 @@
/* cli handling */
int cortex_m3_register_commands(struct command_context_s *cmd_ctx);
int handle_cortex_m3_mask_interrupts_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
+int handle_cortex_m3_dap_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
+int handle_cortex_m3_apsel_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
/* forward declarations */
void cortex_m3_enable_breakpoints(struct target_s *target);
@@ -1581,6 +1583,8 @@
cortex_m3_cmd = register_command(cmd_ctx, NULL, cortex_m3, NULL, COMMAND_ANY, cortex_m3 specific commands);
register_command(cmd_ctx, cortex_m3_cmd, maskisr, handle_cortex_m3_mask_interrupts_command, COMMAND_EXEC, mask cortex_m3 interrupts ['on'|'off']);
+ register_command(cmd_ctx, cortex_m3_cmd, dap, handle_cortex_m3_dap_command, COMMAND_EXEC, dap info for ap [num] (default 0));
+ register_command(cmd_ctx, cortex_m3_cmd, apsel, handle_cortex_m3_apsel_command, COMMAND_EXEC, select a different AP [num] (default 0));
return retval;
}
@@ -1618,3 +1622,62 @@
return ERROR_OK;
}
+
+int handle_cortex_m3_dap_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
+{
+ target_t *target = get_current_target(cmd_ctx);
+ armv7m_common_t *armv7m = target-arch_info;
+ cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
+ swjdp_common_t *swjdp = cortex_m3-swjdp_info;
+
+ u32 dbgbase,apid;
+ u32 apsel,apselold;
+ u8 rev, mem_ap;
+
+ apsel = 0;
+ apselold = swjdp-apsel;
+ if (argc 0)
+ {
+ apsel = strtoul(args[0], NULL, 0);
+ }
+
+
+ swjdp_apselect(swjdp, apsel);
+ ahbap_read_reg_u32(swjdp, 0xF8, dbgbase);
+ ahbap_read_reg_u32(swjdp, 0xFC, apid);
+ swjdp_transaction_endcheck(swjdp);
+ swjdp_apselect(swjdp, apselold);
+ command_print(cmd_ctx, ap debugbase 0x%8.8x, dbgbase);
+ command_print(cmd_ctx, ap identification register 0x%8.8x, apid);
+ if (apid)
+ {
+ mem_ap = (apid16)0x1;
+ }
+
+ return ERROR_OK;
+
+}
+
+int handle_cortex_m3_apsel_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
+{
+ target_t *target = get_current_target(cmd_ctx);
+ armv7m_common_t *armv7m = target-arch_info;
+ cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
+ swjdp_common_t *swjdp = cortex_m3-swjdp_info;
+
+ u32 apsel,apid;
+
+ apsel = 0;
+ if (argc 0)
+ {
+ apsel = strtoul(args[0], NULL, 0);
+ }
+
+ swjdp_apselect(swjdp, apsel);
+ ahbap_read_reg_u32(swjdp, (apsel24)|0xFC, apid);
+ swjdp_transaction_endcheck(swjdp);
+ command_print(cmd_ctx, ap %i selected, identification register 0x%8.8x, apsel, apid);
+
+ return ERROR_OK;
+
+}
Index: src/target/cortex_swjdp.c
===
--- src/target/cortex_swjdp.c (revision 1454)
+++ src/target/cortex_swjdp.c (working copy)
@@ -246,9 +246,10 @@
else
{
u32 dcb_dhcsr,nvic_shcsr, nvic_bfar, nvic_cfsr;
+ u32 ahbap_csv;
/* Print information about last AHBAP access */
- LOG_ERROR(AHBAP: dp_select 0x%x, ap_csw 0x%x, ap_tar 0x%x, swjdp-dp_select_value, swjdp-ap_csw_value, swjdp-ap_tar_value);
+ LOG_ERROR(AHBAP Cached values: dp_select 0x%x, ap_csw 0x%x, ap_tar 0x%x, swjdp-dp_select_value, swjdp-ap_csw_value, swjdp-ap_tar_value);
if (ctrlstat SSTICKYORUN)
LOG_ERROR(SWJ-DP OVERRUN - check clock or reduce jtag speed);
@@ -263,12 +264,20 @@
LOG_DEBUG(swjdp: status 0x%x, ctrlstat);
+ ahbap_read_reg_u32(swjdp, AHBAP_CSW, ahbap_csv);
+ if ((retval=jtag_execute_queue())!=ERROR_OK)
+return retval;
+ LOG_ERROR(Read AHBAP_CSW 0x%x, ahbap_csv);
+
+#if 0
/* Can we find out the reason for the error ?? */
+ /* WARNING This creates an infinite loop when memorymapped core registers cannot be accessed, and no info about SWJDP communicaton problems, REMOVE!!? */
ahbap_read_system_atomic_u32(swjdp, DCB_DHCSR, dcb_dhcsr);
ahbap_read_system_atomic_u32(swjdp, NVIC_SHCSR, nvic_shcsr);
ahbap_read_system_atomic_u32(swjdp, NVIC_CFSR, nvic_cfsr);
ahbap_read_system_atomic_u32(swjdp, NVIC_BFAR, nvic_bfar);
LOG_ERROR(dcb_dhcsr 0x%x,
Re: [Openocd-development] [PATCH] xsvf.c
Committed. I haven't followed this discussion, but I take your word for that there is a consensus that this should be committed. Please check that the patch applied correctly. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html ___ 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?
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 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] Error reporting in flash modules.
On Apr 14, 2009, at 12:09 PM, Øyvind Harboe wrote: On Tue, Apr 14, 2009 at 7:25 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Hi I have commited a patch that gives more readable error reporting for STM32 flash writing errors. But still all errors are reported with the error code ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not very helpul about the cause of the error. My suggestion is to return the more differentiated error codes already available in flash.h without so many verbose messages and then generate meaningful LOG_ERROR text messages in flash.c . ? I'd rather go the other way, not to try to communicate any information through error codes, i.e. to use it *only* as a boolean fail/success. There are only a few places in which the error codes are checked, and I see little reason to expose error codes to the user. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I'd rather know _why_ something failed rather than having to dig through the code to figure out which layer and why. Not every user is a UNIX programmer with intimate knowledge of the targets, interfaces, and general protocols. -- 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 smime.p7s Description: S/MIME cryptographic signature ___ 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?
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 smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Openocd-development] Error reporting in flash modules.
I'd rather know _why_ something failed rather than having to dig through the code to figure out which layer and why. Not every user is a UNIX programmer with intimate knowledge of the targets, interfaces, and general protocols. That's what the LOG_ERROR()'s are for. They tell you where and why. retval's are not propagated consistently or relyably in OpenOCD (or any other C program I've seen really). We could switch to a language with exceptions(C++), but we've had that discussion and there isn't a strong incentive to do so with OpenOCD now that we've got exceptions and resource tracking for menial stuff in Tcl. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to go on with Cortex-A8 support
The reasons First there is no support for interactive commands in cortex_swjdp.c, and ther should not be any. All commands use a swjdp structure for state information. This structure is owned by the target device structure, in our case the cortex_m3 target type so that is the natural place for the user commands. We might move them to to a shared [cortex_dap.c ??] file to support multiple targets and more sofisticated ROM Table walking later. They are EXPERIMENTAL for testing how to talk to more than one AP, I am quite sure they will change a lot when someone starts to do serious experimentation. The command names can easily be changed to anything we like, but lets see if this is useful at all :) Regards, Magnus Rick Altherr wrote: On Apr 14, 2009, at 12:13 PM, Magnus Lundin wrote: Hi The following patch is a first step towards support for sevaral AP in one dap. - Adds a apsel variable, corresponding to the corresponding field in the DP SELECT register, to the swjdap structure. - adds a function swjdp_apselect(swjdp_common_t *swjdp,u8 apsel) to set this variable. - adds two cortex_m3 interactive commands cortex_m3 dap #n Shows the contents of ROM/Debug base register and AP ID Register cortex_m3 apsel #nConfigures to use AP #n in subsequent memory accesses. Shouldn't these be part of the cortex-swjdp rather than tied to the M3? Can we rename them to cortex_swjdap dap #n and cortex_swjdap apsel #n? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error reporting in flash modules.
On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote: I'd rather know _why_ something failed rather than having to dig through the code to figure out which layer and why. Not every user is a UNIX programmer with intimate knowledge of the targets, interfaces, and general protocols. That's what the LOG_ERROR()'s are for. They tell you where and why. retval's are not propagated consistently or relyably in OpenOCD (or any other C program I've seen really). We could switch to a language with exceptions(C++), but we've had that discussion and there isn't a strong incentive to do so with OpenOCD now that we've got exceptions and resource tracking for menial stuff in Tcl. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html So because it isn't that way today, we shouldn't set a policy to do so in the future? -- 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 smime.p7s Description: S/MIME cryptographic signature ___ 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?
As a general matter, anyone doing OSS development on a Mac will already have MacPorts installed. It correctly handles dependency tracking and updating components independently. If you really want to build a standalone package for this, you should just include the libftdi and libusb dylibs. Static libraries just make the binary bigger and make upgrading those components impossible. Rick On Apr 14, 2009, at 1:36 PM, Michael Fischer wrote: 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 -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error reporting in flash modules.
Rick Altherr wrote:
On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote:
I'd rather know _why_ something failed rather than having to dig
through the
code to figure out which layer and why. Not every user is a UNIX
programmer
with intimate knowledge of the targets, interfaces, and general
protocols.
That's what the LOG_ERROR()'s are for. They tell you where and why.
retval's are not propagated consistently or relyably in OpenOCD (or
any other C program I've seen really). We could switch to a language
with exceptions(C++), but we've had that discussion and there isn't
a strong incentive to do so with OpenOCD now that we've got exceptions
and resource tracking for menial stuff in Tcl.
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
So because it isn't that way today, we shouldn't set a policy to do so
in the future?
if( If Rick is speaking out for C++)
{
I second that.
Getting the existing code to compile with C++ is not a large
job. From that point, actually using C++'s useful features can be done
over time.
I dare say 2 days to get the existing code to compile with C++,
at most.
But I would not volunteer for this without write access to some
out of the way branch of the repo during the process.
}
C++ exceptions make error handling easier than C, plus you get type safe
linkage.
Dick
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error reporting in flash modules.
So because it isn't that way today, we shouldn't set a policy to do so in the future? I think that would be moving in the wrong direction, yes. I'm in favour of a boolean success/failure return value and other mechanisms to convey other information. Why should information about what went wrong be limited to 32 bits of information? A c++, java or tcl exception can contain a heck of a lot more useful information. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html ___ 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?
On Apr 14, 2009, at 2:09 PM, Michael Fischer wrote: Hello Rick, As a general matter, anyone doing OSS development on a Mac will already have MacPorts installed. It correctly handles dependency tracking and updating components independently. Yes you are sure, for OSS development. But I think not for embedded development in case of e.g. ARM. If you really want to build a standalone package for this, you should just include the libftdi and libusb dylibs. I can do this, I had copy the dynlibs to the openocd executable but even this was not working. You need to make sure that the dylibs are installed in their final locations. The OS X dylib format includes the absolute path of the dylib when linking. If you move it to another directory, any program linked against it will be looking in the old location. I will give it tomorrow the next try... Best regards, Michael -Ursprungliche Nachricht- Von: Rick Altherr [mailto:kc8...@kc8apf.net] Gesendet: Dienstag, 14. April 2009 23:03 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: AW: [Openocd-development] How to configure the build, without using dynamic libraries? As a general matter, anyone doing OSS development on a Mac will already have MacPorts installed. It correctly handles dependency tracking and updating components independently. If you really want to build a standalone package for this, you should just include the libftdi and libusb dylibs. Static libraries just make the binary bigger and make upgrading those components impossible. Rick On Apr 14, 2009, at 1:36 PM, Michael Fischer wrote: 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 -- 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 -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error reporting in flash modules.
On Apr 14, 2009, at 2:11 PM, Øyvind Harboe wrote: So because it isn't that way today, we shouldn't set a policy to do so in the future? I think that would be moving in the wrong direction, yes. I'm in favour of a boolean success/failure return value and other mechanisms to convey other information. boolean success/failure doesn't really give the programmer a chance to decide what to do. I agree that the usage of return codes in OpenOCD today is a mess, but careful use of well-defined error codes means that a lot of log a message and die conditions today would become handled internally or would be repackaged with a more meaningful error at a higher level. I've just spent 2 years defining a fairly large API entirely in C for a new problem space. After a few false starts, we have managed to design an error system that conveys meaningful error codes to the programmer but also provides ways to map those errors to user-friendly strings that can be presented to the user. All internal errors are mapped onto the same error code space as external errors, but they are handled in a appropriate manner when possible rather than just blindly returning them to the next layer up. This allows the code when to decide to do recovery versus failure. Why should information about what went wrong be limited to 32 bits of information? It doesn't strictly need to be. For example, the API I reference above returns a 32-bit error code but also takes an optional value- return parameter that provides domain-specific error information. These additional parameters can also be stacked so nested failures can be communicated. This ultimately provides a richer and more friendly error system for both the developer as well as the end user of a tool using the API. The return codes are for programmatic handling while the additional parameter is for communicating errors to users. A c++, java or tcl exception can contain a heck of a lot more useful information. And can also cause a lot more problems. Having a deeply nested function throw an exception can cause the upper layers to get in all sorts of weird states. Every layer needs to be aware of what exceptions can be thrown by what functions so that appropriate cleanup can be done. You may as well just return a return code. -- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
