**** BEGIN LOGGING AT Mon Nov 13 02:59:57 2006
Nov 13 10:22:01 <the-moog> Hi,  anybody have the time to offer some help with mixed chains on openocd?
Nov 13 10:27:52 <the-moog> msg nickserv help
Nov 13 10:30:00 <the-moog> ....oops - try putting a / in next time, dumbo
Nov 13 10:30:06 <vmaster> the-moog: hey
Nov 13 10:30:10 <vmaster> the-moog: what exactly do you want?
Nov 13 10:30:22 <vmaster> the-moog: setting up the .cfg for a chain with multiple devices?
Nov 13 10:30:36 <the-moog> Hi,   I'm having some trouble with open ocd and I'm up against it timewise
Nov 13 10:31:07 <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
Nov 13 10:31:51 <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
Nov 13 10:32:11 <vmaster> what chips are in the chain?
Nov 13 10:32:21 <the-moog> From TDI to TDO:
Nov 13 10:32:36 <vmaster> OpenOCD expects them to be listed from TDO to TDI
Nov 13 10:32:44 <the-moog> 1:  CPU Philips/NXP LCP2220
Nov 13 10:33:01 <vmaster> i.e. the one closest to TDO should be listed first as "jtag_device ..."
Nov 13 10:33:29 <the-moog> (yes, I *think* I have the order in .cfg correct)
Nov 13 10:33:40 <the-moog> 2:  FPGA   Altera Cyclone
Nov 13 10:33:54 <the-moog> 3:   CPLD    Lattice powermanager 2
Nov 13 10:34:19 <the-moog> How does openocd know which device is the ARM?
Nov 13 10:34:34 <vmaster> you specify the jtag# in the target line
Nov 13 10:34:46 <vmaster> http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_configuration
Nov 13 10:34:48 <the-moog> ah, perhaps that is what is wrong
Nov 13 10:35:32 <the-moog> my target line reads:
Nov 13 10:35:40 <the-moog> target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
Nov 13 10:36:03 <vmaster> yeah, the 0 means "first target in the chain" (the one closest to TDO)
Nov 13 10:36:15 <vmaster> you should change that to 2 in your case
Nov 13 10:36:24 <the-moog> changing to 2 now......
Nov 13 10:36:25 <vmaster> make sure you're using a current version
Nov 13 10:36:28 <vmaster> of the openocd
Nov 13 10:36:43 <the-moog> btw the target help on the website does not mention this.....
Nov 13 10:37:02 <vmaster> target arm7tdmi <endianess> <reset_mode> <jtag#> [variant]
Nov 13 10:37:03 <vmaster> The arm7tdmi target definition requires at least one additional argument, specifying the position of the target in the JTAG daisy-chain.
Nov 13 10:37:43 <the-moog> YES!!!   responds to halt now  THANK YOU!!
Nov 13 10:37:46 <vmaster> you're welcome
Nov 13 10:38:20 <the-moog> Ok, while you are here,   the flash commands do CFI, i.e. intel, what about AMD?
Nov 13 10:38:36 <the-moog> ...sorry spansion (stupind name if ever there was one)
Nov 13 10:39:07 <vmaster> i've received several patches for spansion, but noone cared to send me something clean enough for inclusion
Nov 13 10:39:42 <the-moog> :(
Nov 13 10:40:18 <vmaster> and while i have several boards with external flashes they all have intel chips
Nov 13 10:40:36 <vmaster> i can send you the last patch i've received, if you want
Nov 13 10:40:53 <vmaster> but you'll have to test it yourself, and make sure that it works correctly
Nov 13 10:41:24 <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
Nov 13 10:42:25 <the-moog> thanks for your help anyway
Nov 13 10:43:02 <vmaster> no problem
Nov 13 10:43:36 <the-moog> I'm just looking at my log from open ocd.  Even though it appears to work, I get:
Nov 13 10:43:48 <the-moog> Warning: jtag.c:1038 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x0
Nov 13 10:43:48 <the-moog> 1 check_mask: 0x00
Nov 13 10:44:20 <the-moog> what is the IR capture exactly?
Nov 13 10:46:42 <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
Nov 13 10:47:42 <vmaster> what type of jtag interface do you use?
Nov 13 10:47:49 <the-moog> amontec jtagkey
Nov 13 10:48:00 <vmaster> what's your jtag_speed setting?
Nov 13 10:48:03 <the-moog> 2
Nov 13 10:48:14 <vmaster> maybe you have to reduce the speed
Nov 13 10:48:36 <vmaster> i.e. increase the jtag_speed value
Nov 13 10:49:41 <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
Nov 13 10:51:24 <vmaster> uhm, yeah, that is strange
Nov 13 10:51:55 <vmaster> can you send me your .cfg and a log (-d -l <logfile>) to Dominic.Rath <at> gmx.de
Nov 13 10:51:58 <vmaster> ?
Nov 13 10:55:48 <the-moog> Ok doing it now.....
Nov 13 11:02:43 <the-moog> ...done
Nov 13 11:03:37 <vmaster> hum, which version of the OpenOCD do you use?
Nov 13 11:04:07 * vmaster note to myself - add that stupid version string to the logoutput, too
Nov 13 11:09:47 <the-moog> good question:  d/l today  - was using 080, now using 115 from http://www.yagarto.de/
Nov 13 11:10:52 <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
Nov 13 11:11:27 <vmaster> yeah, communication failed completely at the end of the logfile you've sent me
Nov 13 11:11:36 <vmaster> Debug:   arm7_9_common.c:620 arm7_9_poll(): DBGACK set, dbg_state->value: 0x4f1f0f0f
Nov 13 11:11:49 <vmaster> that's the JTAG idcode
Nov 13 11:11:55 <the-moog> I tried resume, that seems to break it good
Nov 13 11:12:10 <the-moog> its not an IDCODE from any of the chips in the chain
Nov 13 11:12:35 <vmaster> hum, looks a lot like an ARM idcode
Nov 13 11:12:45 <the-moog> yes?
Nov 13 11:13:23 <the-moog> any idea what the ID code for a LPC2220 should be?
Nov 13 11:13:27 <vmaster> what are the part numbers of the two plds in your design?
Nov 13 11:14:26 <the-moog> ispPAC-POWR1014/A - IDCode: 00145h
Nov 13 11:14:43 <the-moog> oops
Nov 13 11:14:57 <the-moog> 00145043
Nov 13 11:15:03 <the-moog> (h obviously)
Nov 13 11:16:07 <the-moog> Altera EP1C3T144I6
Nov 13 11:16:57 <vmaster> 0x4f1f0f0f is the idcode of my LPC2294
Nov 13 11:19:17 <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
Nov 13 11:19:45 <vmaster> hold on, I'm just checking a few things
Nov 13 11:24:18 <vmaster> hum, the lattice and the altera parts are both capable of >10MHz TCK operation
Nov 13 11:24:43 <vmaster> you don't happen to have the equipment to verify signal integrity on TCK, TMS, TDI and TDO?
Nov 13 11:24:52 <vmaster> especially TMS
Nov 13 11:24:55 <vmaster> and TCK
Nov 13 11:25:40 <vmaster> i'll compile a debug version for you (if i find out how to build for mingw...)
Nov 13 11:27:13 <the-moog> I have a basic storage scope I'll take a look at the tms/tck signals at each chip.
Nov 13 11:58:18 <vmaster> the-moog: http://mmd.ath.cx/openocd/openocd_r115_debug.exe
Nov 13 11:58:59 <the-moog> got it.
Nov 13 11:59:58 <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
Nov 13 12:00:06 <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
Nov 13 12:01:27 <vmaster> ok, try again with the new exe, and send me the log file
Nov 13 12:01:42 <vmaster> you might have to compress it
Nov 13 12:02:05 <the-moog> I've just d/l it - trying it now....
Nov 13 12:03:50 <the-moog> no more log than normal - do I need to use -d <some number>?
Nov 13 12:04:02 <vmaster> mhh, let me check
Nov 13 12:09:50 <vmaster> gnah... gotta love windoze
Nov 13 12:10:04 <vmaster> i'll get myself something for lunch, be back in a few minutes
Nov 13 12:33:38 <vmaster> the-moog: outputs a lot more, as expected - did you run the openocd_r115_debug.exe, not just openocd.exe?
Nov 13 12:33:54 <the-moog> hi
Nov 13 12:34:48 <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
Nov 13 12:36:34 <the-moog> I'll do the same with a -d3 and send you the result from the initialisation
Nov 13 12:58:27 <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...
Nov 13 13:04:11 <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.
Nov 13 13:07:18 <prpplague> vmaster: you see the new lego nxt brick has a SAM series atmel?
Nov 13 13:07:18 <prpplague> vmaster: they even have jtag headers onboard
Nov 13 13:07:43 <prpplague> vmaster: should be able to use openocd with it easy
Nov 13 13:08:44 <vmaster> yeah, they're already using it, at least someone contacted me and asked a few questions
Nov 13 13:09:11 <prpplague> ahh cool
Nov 13 13:09:21 <prpplague> vmaster: the nxt brick is pretty expensive though
Nov 13 13:21:03 <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 
Nov 13 13:43:48 <prpplague> geep-b?
Nov 13 13:44:10 <prpplague> AchiestDragon: sounds like an african hemoragic virus
Nov 13 14:50:19 <vmaster> ~seen lennert
Nov 13 14:50:44 <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'.
**** ENDING LOGGING AT Tue Nov 14 02:59:57 2006