**** BEGIN LOGGING AT Wed Mar 28 02:59:56 2007 Mar 28 08:17:15 Hello drath! Mar 28 08:17:56 Was a pretty long debugging session last friday and yesterday (15hrs in one stretch) Mar 28 08:18:05 finally tracked down the problem in my app Mar 28 08:18:19 but only with help of openocd and especially your help! Mar 28 08:38:56 heh, cool Mar 28 09:28:34 ah ok you there Mar 28 09:29:19 what do you think about extending the flash algorithm so the code erases the sections it intends to flash? Mar 28 09:33:37 hum, well, the current scheme gives greater flexibility, like allowing you to flash sectors in several steps Mar 28 09:33:44 true Mar 28 09:34:09 does the flash algorith very the code? Mar 28 09:34:14 using a crc16 or such? Mar 28 09:34:58 not at all Mar 28 09:35:10 if you meant "verify" Mar 28 09:35:39 verify, yes Mar 28 09:36:02 how do you feel about integrating such? Mar 28 09:36:18 openocd could calculate the given crc16 Mar 28 09:36:45 and after flashing there could run some algorithm in the ram to calculate the actual crcr Mar 28 09:36:46 crc Mar 28 09:37:08 so openocd doesnt have to dump all the info Mar 28 09:37:19 (crc16 is pretty fast and easy if using lookup tables) Mar 28 09:38:06 ok, we could add a CRC16 algorithm, much like the current flash writing algorithms, to safe us from having to read a possibly large area of target memory Mar 28 09:39:18 yes Mar 28 09:39:49 i havent looked into the source code of openocd at all Mar 28 09:39:55 is it c or c++? Mar 28 09:39:57 C Mar 28 09:40:23 would you describe it as, hum, hard to read or understand? Mar 28 09:40:40 (most c++ code i have read ever was plain ugly) Mar 28 09:40:51 the overall structure might be a bit hard to understand, but the code itself is rather straightforward Mar 28 09:41:07 sounds good Mar 28 09:41:21 i will be away for the next to weeks from friday on Mar 28 09:41:28 but after that i wanna look inside Mar 28 09:41:51 well, a verify has always been on my list, and should be pretty easy to implement Mar 28 09:41:54 (having worked on RapidSVN for six years now I am looking for something new...) Mar 28 09:42:03 yes, would think so to Mar 28 09:42:09 we could start with dump-comparing, as that's a lot easier Mar 28 09:42:22 and add CRC16 verification as a speed-up for targets offering a working_area Mar 28 09:42:32 but its time-expensice if its the default Mar 28 09:42:44 s/expensice/expensive/ Mar 28 09:42:46 xela meant: but its time-expensive if its the default Mar 28 09:42:52 the code can automatically fall back to dumping if there's no working_area Mar 28 09:43:23 yes Mar 28 09:43:41 but i guess we wont have the dump-verify enabled by default Mar 28 09:43:49 extra command? or extra option? Mar 28 09:44:11 uhm, no - it would try to use a working_area, and if that fails, it uses the dumping Mar 28 09:44:19 just like the current write algorithms do Mar 28 09:44:43 transparent to the user Mar 28 09:45:14 there are situations where you simply don't have a working area, like when there's only SDRAM which has yet to be initialized Mar 28 09:45:28 but right now, if the jtag speed is low flashing would take twice as long Mar 28 09:45:35 yes Mar 28 09:45:42 yeah, verify would of course be an option Mar 28 09:45:56 i have yet to see flashing fail on any of my devices Mar 28 09:46:04 yes? Mar 28 09:46:13 i dont know if its especially the str750 Mar 28 09:46:25 but here it happens often Mar 28 09:46:40 (LPC2000, STR711, SAM7S, SAM7X and several external Intel flash chips) Mar 28 09:47:03 this is definitely due to a bug Mar 28 09:47:15 the situation is not better when i flash the thing using RLink-Pro Mar 28 09:47:37 oh... Mar 28 09:47:41 flashing fails there, too? Mar 28 09:47:44 the STR711 has a smaller flash, right? Mar 28 09:47:46 yes it does Mar 28 09:47:56 not as often but every third try Mar 28 09:48:13 what eval boards do you work with? Mar 28 09:48:23 flash size of the STR7x depends on the letters after the number, like STR711FR2 -> FR2 Mar 28 09:49:00 the FR2 has 256+16 flash and 64 ram Mar 28 09:49:26 i mostly use the eval boards as testing targets for the openocd, no real projects, aside from getting u-boot and linux to run on the bigger ones Mar 28 09:50:57 so flashing the str711fr2 in one strech works for you? Mar 28 09:51:26 yeah, the whole 256kb in one go Mar 28 09:52:45 so which eval board do you use and which jtag adapter? Mar 28 09:53:20 we are using the Raisonance REva (with several daughter boards) and the Amontec JTagKey Mar 28 09:53:52 an Olimex STR-H711 (header board, just the STR + crystal etc.) with Amontec JTAGkey, JTAGkey-Tiny or Signalyzer Mar 28 09:54:00 they're all FT2232 based so there's no difference Mar 28 09:55:22 hm Mar 28 09:57:45 so i wonder whats happening on my boards Mar 28 09:57:54 (4 MHz crystal) Mar 28 09:58:09 same here Mar 28 09:58:40 hum, is there really no errata for the STR7x - couldn't find any, but I can't believe they got their chips completely right Mar 28 09:59:06 yea Mar 28 10:01:22 where did you get your olimex boards? direct from olimex or from elektronikladen.de Mar 28 10:01:24 ? Mar 28 10:02:38 the STR7 is from my university, don't know where they got it from Mar 28 10:03:07 the others i got directly from Olimex, and one from a hungarian distributor of them Mar 28 10:05:37 i see Mar 28 10:06:58 mikrocontroller.net dont have them :-( Mar 28 10:06:58 they do have other stuff from olimex but not this one Mar 28 10:06:58 ok... have to run... will be back in 2-3 hours Mar 28 10:07:49 ok, bye **** BEGIN LOGGING AT Wed Mar 28 10:36:56 2007 Mar 28 14:09:55 Rehi! Mar 28 15:34:46 so is getting started with jtag complicated? Mar 28 15:35:39 not really. Mar 28 15:36:16 I just ordered some AVR samples with jtag interface, I figure that would be a good starting point. Mar 28 15:36:44 JTAG is used for lots of different purposes - JTAG itself is rather easy Mar 28 15:38:01 it is used for programming, debugging, boundary scan, and in system emulation correct? Mar 28 15:38:28 guess so Mar 28 15:44:29 drath: what is the calling "interface" between openocd and a embedded routine like the flash routine? Mar 28 15:44:36 it gets copied to some ram location Mar 28 15:44:47 then it gets called Mar 28 15:44:52 how does it return? Mar 28 15:46:55 with a breakpoint Mar 28 15:47:23 int armv4_5_run_algorithm(struct target_s *target, int num_mem_params, mem_param_t *mem_params, int num_reg_params, reg_param_t *reg_params, u32 entry_point, u32 exit_point, int timeout_ms, void *arch_info) Mar 28 15:47:34 that's the function that calls the algorithm Mar 28 15:47:52 the code is passed as a mem_param Mar 28 15:48:01 nice Mar 28 15:48:25 so how do you compile the embedded routines? Mar 28 15:48:38 c code using arm-elf-gcc with a simple linker script Mar 28 15:48:59 so you will get a binary with just the function without any surrounding frame? Mar 28 15:49:09 the current routines are all handcrafted assembler ;) Mar 28 15:49:31 the str7x write routine is 80 bytes - i doubt a compiler would do better Mar 28 15:49:47 gcc isnt that bad, i am really astonished about its work Mar 28 15:49:54 just thinking about the crc Mar 28 15:50:10 are the write routines thumb? Mar 28 15:50:15 no, arm Mar 28 15:50:44 yeah, gcc could probably do the same, but having it all in assembler is easier to work with Mar 28 15:51:36 how do you embed the embedded code in the openocd code? Mar 28 15:51:37 like i don't need function prologues etc., that's all done inside the host code, with the right values passed in the register parameters Mar 28 15:51:46 u32 code[] = ;) Mar 28 15:51:47 just memory with the mnemnonics Mar 28 15:52:02 ok Mar 28 15:52:07 this probably needs to be reworked at some time Mar 28 15:52:12 but would be doable with gcc as well. Mar 28 15:52:34 yeah, of course you could use gcc to generate the code Mar 28 15:52:40 arm-elf-gcc (with __naked functions) -> ld -> foo.bin -> script converts to code snipped Mar 28 15:53:10 it just wasn't necessary for the flash write routines, that merely copy data and compare the status Mar 28 15:53:34 true Mar 28 15:53:54 does openocd use autotools for build? Mar 28 15:53:58 yeah Mar 28 15:54:25 good Mar 28 15:54:33 the only target code that goes through cross tools is the XScale debug handler Mar 28 15:54:34 (well, once one has it working...) Mar 28 15:54:43 heh, yeah Mar 28 15:54:48 ah ok, but the skeleton is there Mar 28 15:55:01 (thought about converting RapidSVN from autotools to cmake) Mar 28 15:55:15 if you call target/xscale/build.sh a skeleton, then yes Mar 28 15:55:29 i keep the generated binary in svn Mar 28 15:55:34 as this rarely changes Mar 28 15:55:52 and a user shouldn't need the cross tools to build the debugger Mar 28 15:55:59 i know about the discussions whether or not to version binaries... Mar 28 15:56:33 for customers code we version it as well (together with elf and map) so we can debug without build dependencies (compiler versions and so on) Mar 28 16:08:27 at some point the algorithm handling in openocd needs to be enhanced anyway, like when there's support for non-ARM targets and CFI flashes - the algorithm stuff should then automatically pick the right algorithm file, without a need to duplicate all the generic stuff Mar 28 16:10:46 sounds like future... Mar 28 16:11:05 another question: what is your job situation... how do you find time for openocd? Mar 28 16:11:51 writing my master's thesis, which builds upon the OpenOCD (my diploma thesis project), so currently I still find time to work on it every now and then Mar 28 16:12:28 and once you are dont with your masters thesis? Mar 28 16:12:58 guess i have to get myself a job then ;) but i currently don't have anything special in mind Mar 28 16:13:47 hopefully openocd wont be orphaned then... Mar 28 16:14:21 no, certainly not - i've already put so much time in there i wont let it die Mar 28 16:14:46 good to hear... Mar 28 16:14:56 where in germany are you located anyhow? Mar 28 16:15:33 Augsburg Mar 28 16:16:16 quite close... Ravensburg Mar 28 16:16:38 ah, nice Mar 28 16:17:01 never been there, but it's supposed to be a nice town Mar 28 16:18:42 near the Bodensee and the Alpen... Mar 28 16:18:45 really nice Mar 28 16:19:04 used to have a friend in Koenigsbrunn... liked Augburg a lot Mar 28 16:19:15 heh, actually i live in Koenigsbrunn :) Mar 28 16:19:25 :-) Mar 28 16:19:38 but few people know that, and Augsburg is close enough Mar 28 16:19:39 and i cycled along the Lech a couple of times... really nice Mar 28 16:19:41 Anyone here messed around with the TI ez430 Mar 28 23:48:26 drath: we're sure to have a job for you in Australia when you're finished your masters :-) **** ENDING LOGGING AT Thu Mar 29 02:59:56 2007