**** BEGIN LOGGING AT Wed Mar 21 02:59:56 2007 Mar 21 10:29:31 Hello all Mar 21 10:29:48 I am trying to connect to a STR750 eval board using the Amontec JTagkey Mar 21 10:30:25 Until now I used the Raisonance RLink Pro and I could connect/program/debug without any problems Mar 21 10:30:57 when i try to start the openocd server now (with the config file jtagkey-str7xx.cfg) I get the following error message: Mar 21 10:31:26 Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-17 17:00 CEST) Mar 21 10:31:28 Error: jtag.c:1123 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 3f Mar 21 10:38:40 that's an ancient version - where did you get it from? Mar 21 10:39:35 if you're on linux you should always compile the OpenOCD using the latest sources from svn Mar 21 10:39:51 if you're on windows, get precompiled binaries from www.yagarto.de Mar 21 10:40:21 ah ok Mar 21 10:40:32 I downloaded the stuff from Amontec Mar 21 10:40:44 IIRC the STR750 is an ARM7TDMI-S, as opposed to the previous STR7xx that used to be ARM7TDMI - you must make sure that the JTAG clock is less than 1/6th of the core frequency when using a -S core Mar 21 10:41:21 the Amontec JTAGkey uses a FT2232 that runs at 6MHz / (1 + jtag_speed) - check the crystal on your board and adjust jtag_speed accordingly Mar 21 10:44:04 the crystal on my board is 4Mhz Mar 21 10:45:26 Hm, so I used jtag_speed=9 which would give me 600kHz? Mar 21 10:45:36 Seems like the thing can connect Mar 21 10:45:47 Now I get the warning: Mar 21 10:46:32 Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test logic, too Mar 21 10:46:34 Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0x0f check_value: 0x01 check_mask: 0x0f Mar 21 10:49:12 have you already updated to the current version from Yagarto? Mar 21 10:50:39 that warning indicates a problem with the resets - i've only seen that on NXP LPCs so far, but maybe the latest STRs have the same issue: Mar 21 10:51:09 it looks like the JTAG reset (TRST) gets asserted together with the system reset (SRST) - JTAG communications gets out of synch because of that Mar 21 10:51:36 add "srst_pulls_trst" to the "reset_config" line, and make sure you're not using "reset_halt" or "reset_init" Mar 21 10:54:40 Yes Mar 21 10:55:59 This is my reset_config: Mar 21 10:56:01 reset_config trst_and_srst srst_pulls_trst Mar 21 10:56:10 (sorry, will be away for two hours) Mar 21 10:56:27 Thanks a lot for your help so far! Mar 21 10:56:31 you're welcome Mar 21 10:56:43 just ping me when you have further questions, guess i'll be around the whole afternoon Mar 21 10:56:50 Great! Mar 21 12:21:56 vmaster: hello, i am back... Mar 21 12:24:01 xela: hey Mar 21 12:24:24 This is my reset_config: Mar 21 12:24:28 reset_config trst_and_srst srst_pulls_trst Mar 21 12:26:33 ok, what does the target line look like? Mar 21 12:28:39 target arm7tdmi little run_and_halt 0 arm7tdmi Mar 21 12:28:51 so i guess there should be a -s somewhere? Mar 21 12:29:12 no, that's fine Mar 21 12:29:48 the last "arm7tdmi" isn't evaluated anymore, the necessary information is determined at runtime Mar 21 12:30:03 the STR750 starts up from a freerunning oscillator at about 5mhz Mar 21 12:30:11 try an even lower jtag_speed Mar 21 12:30:22 and add "jtag_ntrst_delay 500" and "jtag_nsrst_delay 500" Mar 21 12:30:54 d'oh, lower jtag clock, i.e. higher jtag_speed setting Mar 21 12:31:32 ah ok Mar 21 12:32:36 the delays make the OpenOCD wait miliseconds after releasing the reset line, allowing for delays introduced by reset supervisors etc. Mar 21 12:37:34 ok Mar 21 12:37:54 Info: openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET) Mar 21 12:37:56 Warning: str7x.c:173 str7x_flash_bank_command(): overriding flash base address for STR71x device with 0x40000000 Mar 21 12:37:57 Warning: str7x.c:173 str7x_flash_bank_command(): overriding flash base address for STR71x device with 0x40000000 Mar 21 12:37:59 Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test logic, too Mar 21 12:38:28 here my latest output (I changed the flash bank setting, since FLASH and RAM are mapped opposite to the layout of the STR71x) Mar 21 12:39:44 ah, ok, the str7x.c needs some work then Mar 21 12:40:07 flashing might be broken atm Mar 21 12:40:49 seems like flashing works Mar 21 12:41:18 (the flash algorithm is the same, we are working on a Bootloader and it works with 71x and 75x now) Mar 21 12:42:09 uhm, what does your flash line look like? I see there's already support for the 75x in str7x.c Mar 21 12:42:31 flash bank str7x 0x20000000 0x00040000 0 0 STR71x 0 Mar 21 12:42:32 flash bank str7x 0x200C0000 0x00004000 0 0 STR71x 0 Mar 21 12:42:47 ok, change the STR71x at the end to STR75x Mar 21 12:43:16 and you only need to define one flash bank Mar 21 12:43:36 the current version treats str7x as one bank, even though there are two physical banks Mar 21 12:43:39 what about B1F0-B1F1? Mar 21 12:43:45 ah ok Mar 21 12:43:53 so the size is 0xC4000? Mar 21 12:44:57 let me check the str75x datasheet - if there's more than one, which one have you got? Mar 21 12:45:14 STR750 Mar 21 12:45:45 our bootloader is in B0F0-B0F1 and B1F0-B1F1 Mar 21 12:45:56 the app is in B0F2-B0F6 Mar 21 12:51:47 ok, the flash layout is similar to that of other STR7x's Mar 21 12:51:53 just set the size to the size of B0 Mar 21 12:52:01 ok Mar 21 12:52:11 0x40000 for the 256K variant Mar 21 12:52:11 but what happens to stuff that has to go into B1? Mar 21 12:52:31 if you check the block layout with "flash info 0" you should see the B1 blocks, too Mar 21 12:52:35 and the correct addresses Mar 21 12:53:01 there'll be a hole between B0 and B1, and the code catches writes beyond B0 and before B1 Mar 21 12:54:52 yes i have checked that Mar 21 12:55:02 great, so far Mar 21 12:55:08 one more thing... Mar 21 12:55:32 soon after reset our code get into the "mud" Mar 21 12:55:42 so i wanna debug right after the reset vector Mar 21 12:56:32 i fear that's going to be a problem - if you have to use "srst_pulls_trst" you wont be able to right out of reset Mar 21 12:57:04 but i could do an endless loop and the set the pc to the adress after that? Mar 21 12:57:15 sure, that's possible Mar 21 12:57:31 just add that at the beginning of the reset handler, and manually advance past that loop Mar 21 12:57:41 yes Mar 21 12:58:08 seems like i do get way better results that with Raisonance Ride so far!!! Mar 21 12:58:17 that=than Mar 21 12:58:27 heh, glad to hear that :) Mar 21 12:59:01 maybe i try this out on my Sendo X too... Mar 21 12:59:03 :-) Mar 21 12:59:37 once your code enables the PLL and switches the processor clock to something > ~30MHz you can increase the JTAG speed again - it's only during startup that the low frequency is necessary Mar 21 12:59:58 ah ok Mar 21 13:00:17 "jtag_speed " is both a configuration option and a user accessible command Mar 21 13:02:55 good! Mar 21 16:36:50 vmaster: you still there? Mar 21 16:37:01 xela: yeah Mar 21 16:37:08 great Mar 21 16:37:17 i am now trying to flash Mar 21 16:37:26 my commands Mar 21 16:38:17 > flash erase 0 0 9 Mar 21 16:38:19 > flash write 0 boot-0.bin 0 Mar 21 16:38:26 gives me several errors: Mar 21 16:38:45 Error: armv4_5.c:584 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target Mar 21 16:38:47 Error: str7x.c:539 str7x_write_block(): error executing str7x flash write algorithm Mar 21 16:38:48 Error: str7x.c:627 str7x_write(): flash writing failed with error code: 0x0 Mar 21 16:39:15 do you have a "working_area" line in your .cfg? Mar 21 16:40:59 yes, but i guess this is bogus: Mar 21 16:41:00 working_area 0 0x4000C000 0x4000 nobackup Mar 21 16:41:38 yeah, look bogus to me - the chip got 16k of SRAM? Mar 21 16:41:44 s/look/loks/ Mar 21 16:41:46 vmaster meant: yeah, loks bogus to me - the chip got 16k of SRAM? Mar 21 16:41:47 doh... Mar 21 16:42:06 try "working_area 0 0x40000000 0x4000 nobackup" Mar 21 16:42:11 yes: changed it to 0x40000000 now Mar 21 16:42:14 for 16kb of SRAM at address 0x40000000 Mar 21 16:42:45 the OpenOCD uses that RAM for a buffer and a small algorithm that does the actual flashing Mar 21 16:43:00 having to use JTAG for every word written would slow down by an order of magnitude Mar 21 16:44:06 yes, sure. Hey this works! Mar 21 16:44:43 vmaster: thanks again, your help saved me days of stupid debugging! Mar 21 16:44:47 you're welcome Mar 21 16:48:37 guess i will add my config to the berlios wiki Mar 21 16:52:06 vmaster: which debugger frontend do you use? Mar 21 16:52:25 i didnt like insight because of lack of syntax coloring Mar 21 16:52:32 you debug inside eclipse? Mar 21 16:53:22 I use eclipse only for editing Mar 21 16:53:32 GDB is enough of a debugger frontend for me Mar 21 16:53:48 :-) Mar 21 16:54:03 uh, maybe i use emacs again Mar 21 16:54:09 hehehe Mar 21 16:54:21 using this when i develop/debug RapidSVN on linux Mar 21 16:55:12 never got used to emacs - either Vim or Eclipse Mar 21 16:55:42 Eclipse is nice for browsing a project, finding defines and so on Mar 21 16:55:51 Vim is a lot faster for editing... Mar 21 16:56:16 ah, xelarellum :) Mar 21 16:56:35 we know each other? Mar 21 16:56:42 or did you just look it up? Mar 21 16:57:02 nah, just googled for rapidsvn Mar 21 16:57:08 :-) Mar 21 16:57:12 yes Mar 21 16:57:16 exactly Mar 21 16:57:22 stuff we do for fun... Mar 21 16:59:24 well, gotta go... Mar 21 16:59:28 have a nice evening **** BEGIN LOGGING AT Wed Mar 21 23:22:38 2007 **** BEGIN LOGGING AT Wed Mar 21 23:43:25 2007 **** ENDING LOGGING AT Thu Mar 22 02:59:58 2007