| 04:59.18 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 06:44.58 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 08:18.08 | *** join/#openjtag nslu2-log_ (n=nslu2-lo@nslu2-linux/dyoung) |
| 09:56.24 | *** join/#openjtag vmaster_ (i=vmaster@p549B53F4.dip.t-dialin.net) |
| 10:43.53 | *** join/#openjtag the-moog (n=the-moog@static-195-248-121-199.adsl.hotchilli.net) |
| 10:44.42 | the-moog | Hi, anybody have the time to offer some help with mixed chains on openocd? |
| 10:50.28 | the-moog | msg nickserv help |
| 10:52.36 | the-moog | ....oops - try putting a / in next time, dumbo |
| 10:52.41 | vmaster | the-moog: hey |
| 10:52.46 | vmaster | the-moog: what exactly do you want? |
| 10:52.58 | vmaster | the-moog: setting up the .cfg for a chain with multiple devices? |
| 10:53.12 | the-moog | Hi, I'm having some trouble with open ocd and I'm up against it timewise |
| 10:53.43 | the-moog | I've just got a new board back, up 'till now I've been using an olimex dev board, that has worked fine |
| 10:54.27 | the-moog | I can use lattce isp on the mixed chain, but I can't get openocd to work, perhaps you would have time to point me in the right direction |
| 10:54.47 | vmaster | what chips are in the chain? |
| 10:54.57 | the-moog | From TDI to TDO: |
| 10:55.11 | vmaster | OpenOCD expects them to be listed from TDO to TDI |
| 10:55.19 | the-moog | 1: CPU Philips/NXP LCP2220 |
| 10:55.36 | vmaster | i.e. the one closest to TDO should be listed first as "jtag_device ..." |
| 10:56.04 | the-moog | (yes, I *think* I have the order in .cfg correct) |
| 10:56.16 | the-moog | 2: FPGA Altera Cyclone |
| 10:56.30 | the-moog | 3: CPLD Lattice powermanager 2 |
| 10:56.55 | the-moog | How does openocd know which device is the ARM? |
| 10:57.09 | vmaster | you specify the jtag# in the target line |
| 10:57.21 | vmaster | http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_configuration |
| 10:57.23 | the-moog | ah, perhaps that is what is wrong |
| 10:58.08 | the-moog | my target line reads: |
| 10:58.16 | the-moog | target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4 |
| 10:58.39 | vmaster | yeah, the 0 means "first target in the chain" (the one closest to TDO) |
| 10:58.51 | vmaster | you should change that to 2 in your case |
| 10:58.59 | the-moog | changing to 2 now...... |
| 10:59.01 | vmaster | make sure you're using a current version |
| 10:59.03 | vmaster | of the openocd |
| 10:59.18 | the-moog | btw the target help on the website does not mention this..... |
| 10:59.38 | vmaster | target arm7tdmi <endianess> <reset_mode> <jtag#> [variant] |
| 10:59.38 | vmaster | The arm7tdmi target definition requires at least one additional argument, specifying the position of the target in the JTAG daisy-chain. |
| 11:00.16 | the-moog | YES!!! responds to halt now THANK YOU!! |
| 11:00.21 | vmaster | you're welcome |
| 11:00.54 | the-moog | Ok, while you are here, the flash commands do CFI, i.e. intel, what about AMD? |
| 11:01.12 | the-moog | ...sorry spansion (stupind name if ever there was one) |
| 11:01.43 | vmaster | i've received several patches for spansion, but noone cared to send me something clean enough for inclusion |
| 11:02.18 | the-moog | :( |
| 11:02.54 | vmaster | and while i have several boards with external flashes they all have intel chips |
| 11:03.12 | vmaster | i can send you the last patch i've received, if you want |
| 11:03.29 | vmaster | but you'll have to test it yourself, and make sure that it works correctly |
| 11:04.01 | the-moog | I probably have no time to play and build the windoze port - or even the tools to do it, no worries, I'll work round somehow |
| 11:05.01 | the-moog | thanks for your help anyway |
| 11:05.38 | vmaster | no problem |
| 11:06.12 | the-moog | I'm just looking at my log from open ocd. Even though it appears to work, I get: |
| 11:06.24 | the-moog | Warning: jtag.c:1038 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x0 |
| 11:06.24 | the-moog | 1 check_mask: 0x00 |
| 11:06.56 | the-moog | what is the IR capture exactly? |
| 11:09.17 | vmaster | when scanning instructions in the JTAG instruction register, every chip is expected to load "b01" into the two least significant bits of the IR register, which are then shifted out. the ARMs actually shift out b0001. the OpenOCD uses these values to verify that communication is working correctly |
| 11:10.18 | vmaster | what type of jtag interface do you use? |
| 11:10.25 | the-moog | amontec jtagkey |
| 11:10.36 | vmaster | what's your jtag_speed setting? |
| 11:10.38 | the-moog | 2 |
| 11:10.50 | vmaster | maybe you have to reduce the speed |
| 11:11.11 | vmaster | i.e. increase the jtag_speed value |
| 11:12.18 | the-moog | the strange thing is the check mask in the error log report is 0x00, but in the config file it is all 1's |
| 11:13.59 | vmaster | uhm, yeah, that is strange |
| 11:14.31 | vmaster | can you send me your .cfg and a log (-d -l <logfile>) to Dominic.Rath <at> gmx.de |
| 11:14.34 | vmaster | ? |
| 11:18.24 | the-moog | Ok doing it now..... |
| 11:25.19 | the-moog | ...done |
| 11:26.13 | vmaster | hum, which version of the OpenOCD do you use? |
| 11:32.21 | the-moog | good question: d/l today - was using 080, now using 115 from http://www.yagarto.de/ |
| 11:33.28 | the-moog | It looks like there is some corruption of the jtag chain. I've just tried setting registers using reg <num> <data> and the register value is wrong |
| 11:34.02 | vmaster | yeah, communication failed completely at the end of the logfile you've sent me |
| 11:34.11 | vmaster | Debug: arm7_9_common.c:620 arm7_9_poll(): DBGACK set, dbg_state->value: 0x4f1f0f0f |
| 11:34.24 | vmaster | that's the JTAG idcode |
| 11:34.31 | the-moog | I tried resume, that seems to break it good |
| 11:34.46 | the-moog | its not an IDCODE from any of the chips in the chain |
| 11:35.11 | vmaster | hum, looks a lot like an ARM idcode |
| 11:35.21 | the-moog | yes? |
| 11:35.59 | the-moog | any idea what the ID code for a LPC2220 should be? |
| 11:36.03 | vmaster | what are the part numbers of the two plds in your design? |
| 11:37.02 | the-moog | ispPAC-POWR1014/A - IDCode: 00145h |
| 11:37.19 | the-moog | oops |
| 11:37.33 | the-moog | 00145043 |
| 11:37.39 | the-moog | (h obviously) |
| 11:38.43 | the-moog | Altera EP1C3T144I6 |
| 11:39.32 | vmaster | 0x4f1f0f0f is the idcode of my LPC2294 |
| 11:41.53 | the-moog | I can't find a reliable source for ID code for altera, I was using the latice ISP software yesterday and that listes all the ids |
| 11:42.21 | vmaster | hold on, I'm just checking a few things |
| 11:46.54 | vmaster | hum, the lattice and the altera parts are both capable of >10MHz TCK operation |
| 11:47.19 | vmaster | you don't happen to have the equipment to verify signal integrity on TCK, TMS, TDI and TDO? |
| 11:47.27 | vmaster | especially TMS |
| 11:47.30 | vmaster | and TCK |
| 11:48.16 | vmaster | i'll compile a debug version for you (if i find out how to build for mingw...) |
| 11:49.49 | the-moog | I have a basic storage scope I'll take a look at the tms/tck signals at each chip. |
| 12:20.54 | vmaster | the-moog: http://mmd.ath.cx/openocd/openocd_r115_debug.exe |
| 12:21.35 | the-moog | got it. |
| 12:22.34 | vmaster | this one includes a fix for comparing the jtag data that didn't make it into R115, and is going to output a lot of debug info |
| 12:22.42 | the-moog | I've been playing with the scope, but can't make sense of what is going on. The scope is not very good at capturing fast, non repetative signals - but the levels vs noise look ok |
| 12:24.03 | vmaster | ok, try again with the new exe, and send me the log file |
| 12:24.18 | vmaster | you might have to compress it |
| 12:24.41 | the-moog | I've just d/l it - trying it now.... |
| 12:26.26 | the-moog | no more log than normal - do I need to use -d <some number>? |
| 12:26.37 | vmaster | mhh, let me check |
| 12:32.25 | vmaster | gnah... gotta love windoze |
| 12:32.40 | vmaster | i'll get myself something for lunch, be back in a few minutes |
| 12:56.14 | vmaster | the-moog: outputs a lot more, as expected - did you run the openocd_r115_debug.exe, not just openocd.exe? |
| 12:56.30 | the-moog | hi |
| 12:57.24 | the-moog | yes I ran the correct one - jet me just check that I have done this right. I just copied the .exe you sent into the install folder\bin of openocd |
| 12:59.11 | the-moog | I'll do the same with a -d3 and send you the result from the initialisation |
| 13:06.59 | *** join/#openjtag prpplague (n=billybob@72.22.146.236) |
| 13:21.03 | vmaster | the-moog: there's definitely a communication problem, but there might also be a bug somewhere... the value 0x01 reported as the check_mask is wrong, it should be 0xf... |
| 13:26.48 | the-moog | There are some mods I can do to shorten the chain - I will do this after lunch. I will report back when the chain only has the ARM present if there is still a problem. |
| 13:29.46 | prpplague | vmaster: you see the new lego nxt brick has a SAM series atmel? |
| 13:29.54 | prpplague | vmaster: they even have jtag headers onboard |
| 13:30.17 | prpplague | vmaster: should be able to use openocd with it easy |
| 13:31.20 | vmaster | yeah, they're already using it, at least someone contacted me and asked a few questions |
| 13:31.46 | prpplague | ahh cool |
| 13:31.57 | prpplague | vmaster: the nxt brick is pretty expensive though |
| 13:43.15 | *** join/#openjtag purl (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 13:43.15 | *** topic/#openjtag is This is the place to discuss JTAG and Bootloaders |
| 13:43.40 | AchiestDragon | just working on a ui for the programming/communications pc frontend for the geep-b , but pondering if i should be using qt3.x or qt4 |
| 14:06.25 | prpplague | geep-b? |
| 14:06.47 | prpplague | AchiestDragon: sounds like an african hemoragic virus |
| 15:12.56 | vmaster | ~seen lennert |
| 15:13.21 | purl | lennert <n=buytenh@nslu2-linux/lennert> was last seen on IRC in channel #openjtag, 5d 4h 40m 31s ago, saying: 'probably LE as that's what other folks use'. |
| 15:49.28 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 15:50.05 | *** join/#openjtag dwery (n=dwery@81-208-60-204.ip.fastwebnet.it) |
| 17:07.08 | *** join/#openjtag tibal (n=tibal@82.232.88.10) |
| 19:38.34 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 23:21.38 | *** join/#openjtag bullet (n=bullet@168.23.79.83.cust.bluewin.ch) |