| 00:55.01 | *** join/#openjtag p2-mate_ (n=p2@cable-87-244-173-194.upc.chello.be) |
| 00:57.56 | *** join/#openjtag p2-mate_ (n=p2@cable-87-244-173-194.upc.chello.be) |
| 02:19.30 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 02:24.19 | *** join/#openjtag nslu2-log (n=nslu2-lo@nslu2-linux/dyoung) |
| 04:25.13 | *** part/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 06:34.57 | *** join/#openjtag AchiestDragon_ (n=david@whipy.demon.co.uk) |
| 06:42.01 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
| 06:42.55 | *** join/#openjtag rd_ (n=redragon@vnsecurity.net) |
| 06:57.06 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
| 07:26.44 | *** join/#openjtag aproemel (n=aproemel@www-cache.bocholt.fh-gelsenkirchen.de) |
| 08:25.15 | *** join/#openjtag p2-mate (n=p2@cable-87-244-173-194.upc.chello.be) |
| 10:29.02 | *** join/#openjtag xela (n=chatzill@p549c9867.dip0.t-ipconnect.de) |
| 10:29.31 | xela | Hello all |
| 10:29.48 | xela | I am trying to connect to a STR750 eval board using the Amontec JTagkey |
| 10:30.25 | xela | Until now I used the Raisonance RLink Pro and I could connect/program/debug without any problems |
| 10:31.08 | xela | when i try to start the openocd server now (with the config file jtagkey-str7xx.cfg) I get the following error message: |
| 10:31.26 | xela | Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-17 17:00 CEST) |
| 10:31.28 | xela | Error: jtag.c:1123 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 3f |
| 10:38.40 | vmaster | that's an ancient version - where did you get it from? |
| 10:39.35 | vmaster | if you're on linux you should always compile the OpenOCD using the latest sources from svn |
| 10:39.51 | vmaster | if you're on windows, get precompiled binaries from www.yagarto.de |
| 10:40.21 | xela | ah ok |
| 10:40.33 | xela | I downloaded the stuff from Amontec |
| 10:40.44 | vmaster | 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 |
| 10:41.21 | vmaster | the Amontec JTAGkey uses a FT2232 that runs at 6MHz / (1 + jtag_speed) - check the crystal on your board and adjust jtag_speed accordingly |
| 10:44.04 | xela | the crystal on my board is 4Mhz |
| 10:45.26 | xela | Hm, so I used jtag_speed=9 which would give me 600kHz? |
| 10:45.36 | xela | Seems like the thing can connect |
| 10:45.47 | xela | Now I get the warning: |
| 10:46.33 | xela | Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test logic, too |
| 10:46.34 | xela | 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 |
| 10:49.13 | vmaster | have you already updated to the current version from Yagarto? |
| 10:50.39 | vmaster | 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: |
| 10:51.09 | vmaster | it looks like the JTAG reset (TRST) gets asserted together with the system reset (SRST) - JTAG communications gets out of synch because of that |
| 10:51.36 | vmaster | add "srst_pulls_trst" to the "reset_config" line, and make sure you're not using "reset_halt" or "reset_init" |
| 10:54.40 | xela | Yes |
| 10:55.59 | xela | This is my reset_config: |
| 10:56.01 | xela | reset_config trst_and_srst srst_pulls_trst |
| 10:56.10 | xela | (sorry, will be away for two hours) |
| 10:56.27 | xela | Thanks a lot for your help so far! |
| 10:56.31 | vmaster | you're welcome |
| 10:56.43 | vmaster | just ping me when you have further questions, guess i'll be around the whole afternoon |
| 10:56.50 | xela | Great! |
| 12:03.09 | *** join/#openjtag rwhitby (n=nrwhitby@nslu2-linux/rwhitby) |
| 12:21.56 | xela | vmaster: hello, i am back... |
| 12:24.01 | vmaster | xela: hey |
| 12:24.24 | xela | This is my reset_config: |
| 12:24.28 | xela | reset_config trst_and_srst srst_pulls_trst |
| 12:26.33 | vmaster | ok, what does the target line look like? |
| 12:28.40 | xela | target arm7tdmi little run_and_halt 0 arm7tdmi |
| 12:28.51 | xela | so i guess there should be a -s somewhere? |
| 12:29.12 | vmaster | no, that's fine |
| 12:29.58 | vmaster | the last "arm7tdmi" isn't evaluated anymore, the necessary information is determined at runtime |
| 12:30.03 | vmaster | the STR750 starts up from a freerunning oscillator at about 5mhz |
| 12:30.12 | vmaster | try an even lower jtag_speed |
| 12:30.23 | vmaster | and add "jtag_ntrst_delay 500" and "jtag_nsrst_delay 500" |
| 12:30.54 | vmaster | d'oh, lower jtag clock, i.e. higher jtag_speed setting |
| 12:31.32 | xela | ah ok |
| 12:32.37 | vmaster | the delays make the OpenOCD wait <n> miliseconds after releasing the reset line, allowing for delays introduced by reset supervisors etc. |
| 12:37.34 | xela | ok |
| 12:37.54 | xela | Info: openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET) |
| 12:37.56 | xela | Warning: str7x.c:173 str7x_flash_bank_command(): overriding flash base address for STR71x device with 0x40000000 |
| 12:37.57 | xela | Warning: str7x.c:173 str7x_flash_bank_command(): overriding flash base address for STR71x device with 0x40000000 |
| 12:37.59 | xela | Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test logic, too |
| 12:38.28 | xela | here my latest output (I changed the flash bank setting, since FLASH and RAM are mapped opposite to the layout of the STR71x) |
| 12:39.44 | vmaster | ah, ok, the str7x.c needs some work then |
| 12:40.07 | vmaster | flashing might be broken atm |
| 12:40.49 | xela | seems like flashing works |
| 12:41.18 | xela | (the flash algorithm is the same, we are working on a Bootloader and it works with 71x and 75x now) |
| 12:42.09 | vmaster | uhm, what does your flash line look like? I see there's already support for the 75x in str7x.c |
| 12:42.31 | xela | flash bank str7x 0x20000000 0x00040000 0 0 STR71x 0 |
| 12:42.32 | xela | flash bank str7x 0x200C0000 0x00004000 0 0 STR71x 0 |
| 12:42.47 | vmaster | ok, change the STR71x at the end to STR75x |
| 12:43.16 | vmaster | and you only need to define one flash bank |
| 12:43.36 | vmaster | the current version treats str7x as one bank, even though there are two physical banks |
| 12:43.39 | xela | what about B1F0-B1F1? |
| 12:43.45 | xela | ah ok |
| 12:43.53 | xela | so the size is 0xC4000? |
| 12:44.57 | vmaster | let me check the str75x datasheet - if there's more than one, which one have you got? |
| 12:45.14 | xela | STR750 |
| 12:45.18 | *** join/#openjtag rd_ (n=redragon@vnsecurity.net) |
| 12:45.45 | xela | our bootloader is in B0F0-B0F1 and B1F0-B1F1 |
| 12:45.56 | xela | the app is in B0F2-B0F6 |
| 12:51.47 | vmaster | ok, the flash layout is similar to that of other STR7x's |
| 12:51.54 | vmaster | just set the size to the size of B0 |
| 12:52.01 | xela | ok |
| 12:52.11 | vmaster | 0x40000 for the 256K variant |
| 12:52.11 | xela | but what happens to stuff that has to go into B1? |
| 12:52.32 | vmaster | if you check the block layout with "flash info 0" you should see the B1 blocks, too |
| 12:52.35 | vmaster | and the correct addresses |
| 12:53.01 | vmaster | there'll be a hole between B0 and B1, and the code catches writes beyond B0 and before B1 |
| 12:54.52 | xela | yes i have checked that |
| 12:55.02 | xela | great, so far |
| 12:55.08 | xela | one more thing... |
| 12:55.32 | xela | soon after reset our code get into the "mud" |
| 12:55.42 | xela | so i wanna debug right after the reset vector |
| 12:56.32 | vmaster | 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 |
| 12:57.04 | xela | but i could do an endless loop and the set the pc to the adress after that? |
| 12:57.15 | vmaster | sure, that's possible |
| 12:57.31 | vmaster | just add that at the beginning of the reset handler, and manually advance past that loop |
| 12:57.41 | xela | yes |
| 12:57.57 | *** join/#openjtag bullet (n=bullet@23.211.62.81.cust.bluewin.ch) |
| 12:58.08 | xela | seems like i do get way better results that with Raisonance Ride so far!!! |
| 12:58.17 | xela | that=than |
| 12:58.27 | vmaster | heh, glad to hear that :) |
| 12:59.01 | xela | maybe i try this out on my Sendo X too... |
| 12:59.03 | xela | :-) |
| 12:59.37 | vmaster | 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 |
| 12:59.58 | xela | ah ok |
| 13:00.18 | vmaster | "jtag_speed <n>" is both a configuration option and a user accessible command |
| 13:02.55 | xela | good! |
| 13:21.46 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:59.09 | *** join/#openjtag purl (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 13:59.09 | *** topic/#openjtag is this is the place to discuss bootloaders and JTAG |
| 16:31.00 | *** join/#openjtag muasch|swiss15 (n=muasch@31.14.3.213.fix.bluewin.ch) |
| 16:36.50 | xela | vmaster: you still there? |
| 16:37.01 | vmaster | xela: yeah |
| 16:37.08 | xela | great |
| 16:37.17 | xela | i am now trying to flash |
| 16:37.26 | xela | my commands |
| 16:38.17 | xela | > flash erase 0 0 9 |
| 16:38.19 | xela | > flash write 0 boot-0.bin 0 |
| 16:38.27 | xela | gives me several errors: |
| 16:38.45 | xela | Error: armv4_5.c:584 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target |
| 16:38.47 | xela | Error: str7x.c:539 str7x_write_block(): error executing str7x flash write algorithm |
| 16:38.48 | xela | Error: str7x.c:627 str7x_write(): flash writing failed with error code: 0x0 |
| 16:39.15 | vmaster | do you have a "working_area" line in your .cfg? |
| 16:40.59 | xela | yes, but i guess this is bogus: |
| 16:41.01 | xela | working_area 0 0x4000C000 0x4000 nobackup |
| 16:41.38 | vmaster | yeah, look bogus to me - the chip got 16k of SRAM? |
| 16:41.44 | vmaster | s/look/loks/ |
| 16:41.47 | vmaster | doh... |
| 16:42.06 | vmaster | try "working_area 0 0x40000000 0x4000 nobackup" |
| 16:42.11 | xela | yes: changed it to 0x40000000 now |
| 16:42.14 | vmaster | for 16kb of SRAM at address 0x40000000 |
| 16:42.45 | vmaster | the OpenOCD uses that RAM for a buffer and a small algorithm that does the actual flashing |
| 16:43.00 | vmaster | having to use JTAG for every word written would slow down by an order of magnitude |
| 16:44.06 | xela | yes, sure. Hey this works! |
| 16:44.43 | xela | vmaster: thanks again, your help saved me days of stupid debugging! |
| 16:44.47 | vmaster | you're welcome |
| 16:48.37 | xela | guess i will add my config to the berlios wiki |
| 16:52.06 | xela | vmaster: which debugger frontend do you use? |
| 16:52.25 | xela | i didnt like insight because of lack of syntax coloring |
| 16:52.32 | xela | you debug inside eclipse? |
| 16:53.22 | vmaster | I use eclipse only for editing |
| 16:53.32 | vmaster | GDB is enough of a debugger frontend for me |
| 16:53.48 | xela | :-) |
| 16:54.03 | xela | uh, maybe i use emacs again |
| 16:54.09 | vmaster | hehehe |
| 16:54.21 | xela | using this when i develop/debug RapidSVN on linux |
| 16:55.12 | vmaster | never got used to emacs - either Vim or Eclipse |
| 16:55.42 | vmaster | Eclipse is nice for browsing a project, finding defines and so on |
| 16:55.51 | vmaster | Vim is a lot faster for editing... |
| 16:56.16 | vmaster | ah, xelarellum :) |
| 16:56.36 | xela | we know each other? |
| 16:56.42 | xela | or did you just look it up? |
| 16:57.02 | vmaster | nah, just googled for rapidsvn |
| 16:57.08 | xela | :-) |
| 16:57.12 | xela | yes |
| 16:57.16 | xela | exactly |
| 16:57.22 | xela | stuff we do for fun... |
| 16:59.24 | xela | well, gotta go... |
| 16:59.28 | xela | have a nice evening |
| 17:18.09 | *** join/#openjtag muasch|swiss16 (n=muasch@31.14.3.213.fix.bluewin.ch) |
| 17:19.14 | *** join/#openjtag muasch|swiss17 (n=muasch@31.14.3.213.fix.bluewin.ch) |
| 17:27.43 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 18:45.06 | *** join/#openjtag rd__ (n=redragon@vnsecurity.net) |
| 19:08.49 | *** join/#openjtag vmaster_ (i=vmaster@p5b07fa92.dip.t-dialin.net) |
| 20:25.53 | *** join/#openjtag muasch|swiss18 (n=muasch@31.14.3.213.fix.bluewin.ch) |
| 20:45.10 | *** join/#openjtag muasch|swiss19 (n=muasch@31.14.3.213.fix.bluewin.ch) |
| 21:02.38 | *** join/#openjtag muasch|swiss110 (n=muasch@31.14.3.213.fix.bluewin.ch) |
| 22:49.35 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 23:22.38 | *** join/#openjtag nslu2-log_ (n=nslu2-lo@nslu2-linux/dyoung) |
| 23:43.25 | *** join/#openjtag nslu2-log_ (n=nslu2-lo@nslu2-linux/dyoung) |