**** BEGIN LOGGING AT Thu Jan 14 02:59:57 2010 Jan 14 08:27:58 having problems building openocd under linux/Ubuntu, anybody care to lend a hand? Config script says that the libftdi compile test fails. I have tried libftdi-dev package and compiling/installing libftdi from source. Jan 14 08:50:18 the-moog: have you tried looking at config.log? Jan 14 08:50:28 the-moog: the reason for the script failing should be pretty obvious from that Jan 14 08:56:24 yes, it says it can't find libftdi.so.1, this path is in /usr/local/lib which is listed ld.so.conf Jan 14 09:58:48 the-moog: who says? the linker? Jan 14 09:58:54 the-moog: can you pastebin the log? Jan 14 09:59:22 the-moog: are you sure to have done "ldconfig" after you installed libftdi from source? Jan 14 10:17:49 I would have thought make instal did ldconfig? But I will give it a go anyway.... Jan 14 10:20:10 yep, you were right, libftdi did not do the ldconfig - thanks Jan 14 10:31:42 the-moog: welcome Jan 14 10:38:34 ok, it builds but report "Command handler execution filed", seems like a log way of saying "something happened" Jan 14 10:39:28 *failed = filed Jan 14 10:42:30 interesting, it works with a shipped config file, but not with mine, even though the binary / windows one does. Jan 14 10:46:16 hi Jan 14 10:46:27 does anybody owns an Amontec JTAG adaptor? Jan 14 10:46:34 JTAG tiny Jan 14 10:47:58 I've got the JTAGkey (not the tiny) Jan 14 10:51:27 I think the non-tiny is more sensitive Jan 14 10:51:35 supports more voltages Jan 14 11:58:13 the-moog: i'm trying to debug a weird stack (?) corruption here on windows that doesn't occur with GNU/Linux... Shows its ugly face when i use flash write_bank command... So who knows what other bugs are still hiding there. Better use a decent os for development, this way you can easily debug openocd itself. Jan 14 13:50:49 PaulFertser: That is what I am having to do. Up to now I've always used windows openocd - because it just works, has done for years. But now I need to use SVF and that dies with a stupid error. Though't I'd build it on Linux to find why its dying only to find building it is not as straight forward as all that..... Jan 14 13:52:59 Sorry,I don't think I help with the windows stack problems either, I usually program ARMs. Jan 14 13:53:54 the-moog: building on GNU/Linux is really straight forward. In fact cross-compiling with mingw is straight-forward too. Jan 14 13:54:13 the-moog: i was just unfortunate enough to hit a 2-year old bug still not fixed in debian :( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452977 Jan 14 13:54:37 the-moog: so did you finally build it, what is your issue now? Jan 14 13:58:41 ok, it builds but report "Command handler execution filed", seems like a log way of saying "something happened" Jan 14 13:59:03 I then try a as-shipped config file for JTAGkey and it works. Jan 14 14:00:04 the-moog: so the build doesn't seem to be a problem, right? Or do you suspect it uses some wrong libusb/ftdi version? Jan 14 14:00:20 My config file works with the windows binary, obviously a bug but no time to look into it right now (unless it acually affects me) Jan 14 14:00:51 the-moog: can it be that's due to the version difference? Jan 14 14:03:13 I'm using 3.1 source code so unless the git tree is wrong or perhaps the binary maintainer fixed bugs without submitting - dunno Jan 14 14:04:30 the-moog: i'm sorry but i can't help much without more specifics, debugging information and such. Jan 14 14:06:51 Now I see another problem. I think the source is not clean. If I put reset_config in the config file it says it must be called after jtag init, but if I put jtag init in the config file it says it is already called. Jan 14 14:07:03 Goning to try the 4.0 rc1 code Jan 14 14:09:00 I've seen this lots with openOCD the parsing code is a heap of poo, both command line and config files. Jan 14 14:09:21 I'm expecing it is the same problem with the svf parser. Jan 14 14:09:27 *expecting Jan 14 14:10:59 same :( Jan 14 14:34:33 Thought so, the code for svf.c has a stupid error, check out this line: Jan 14 14:34:35 if ((num_of_argu > 10) || (num_of_argu % 2)) Jan 14 14:34:35 { Jan 14 14:34:35 LOG_ERROR("invalid parameter of %s", argus[0]); Jan 14 14:34:35 return ERROR_FAIL; Jan 14 14:34:36 } Jan 14 14:35:17 num_of_argu is always odd (1,3,5,7,9, etc) so num_if_argu % 2 is always 1 which means it always fails. Jan 14 14:35:39 Now: How to build under windows........? Jan 14 15:01:27 Hm, the problem is more fundamental, the person who write it did not read the spec properly and assumed that a space is always the delimieter between the signal and its value, e.g. TDI(123) when it can be TDI(123) Jan 14 15:02:04 I'll raise a bug and write a parser to fixup the SVF files, it will be quicker. Jan 14 22:06:25 Still having problems with SVF in OpenJTAG, this time its lower level, perhaps some sort of buffer overrun or lockup in the libftdi driver - no idea how to debug it though. Jan 14 22:06:29 ftdi_write_data: usb bulk write failed Jan 14 22:06:29 couldn't write MPSSE commands to FT2232 Jan 14 22:06:54 Short SVF files <1000 odd lines are fine, longer ones screw up. Jan 14 22:10:13 maybe it tries to send too much Jan 14 22:11:17 try putting around the place of error a printf with number of bytes Jan 14 22:23:14 the word 'bulk' does not occur in the OpenOCD code, so it must be in the libftdi driver. Jan 14 22:26:23 ....which it is. Jan 14 22:27:22 I guess this means it could be a bug in the firmware of the ftdi device. Jan 14 22:47:27 look for ftdi_write_data Jan 14 22:47:41 the error message is looked up Jan 14 23:01:17 if ((retval = ftdi_write_data(&ftdic, buf, size)) < 0) Jan 14 23:01:17 { Jan 14 23:01:17 *bytes_written = 0; Jan 14 23:01:17 ERROR("ftdi_write_data: %s", ftdi_get_error_string(&ftdic)); Jan 14 23:01:18 return ERROR_JTAG_DEVICE_ERROR; Jan 14 23:01:19 } Jan 14 23:05:57 indeed, but that message comes from the driver so I don't think its the openocd that is going wrong, more like the driver or even the firmware. Jan 14 23:06:38 I'm going to implement internal programming, I think this will be easier. Jan 14 23:53:33 just add a printf before the message, so you can at least know which size triggers it **** ENDING LOGGING AT Fri Jan 15 02:59:57 2010