**** BEGIN LOGGING AT Mon Dec 29 02:59:56 2008 Dec 29 21:09:07 Anybody listening out in the ether? Dec 29 21:10:07 Yup. But not many talkers. Dec 29 21:10:44 Darn, I'm looking for some help understanding what could be wrong with my JTAG setup in OpenOCD. Dec 29 21:10:53 I can't halt the board, it just times out waiting for it. Dec 29 21:11:28 Unfortunately, I'm not going to be able to be of much help. I'm a bit of a newbie. Dec 29 21:11:46 Darn, all the nubes hang out here (including me) Dec 29 21:11:56 Sorry, n00bs. Dec 29 21:12:09 There is a lot more traffic on the list. Dec 29 21:12:16 More than here, anyway. Dec 29 21:12:48 Especially when I'm trying to get a patch accepted. ;) Dec 29 21:13:29 Yeah, the list at list has some talkers. Dec 29 21:14:01 I'm working on getting a config script together for an Olimex board, but I don't know how to make sure things work :D Dec 29 21:14:28 It would be nice if there were a tutorial somewhere. Maybe there even is, but I haven't found it. Dec 29 21:15:03 Well, the docs have a full list of commands the OpenOCD handles, I just don't have a clue why they would fail. Dec 29 21:15:17 It could just be a misconfigured system or some such. Dec 29 21:15:57 Where exactly are you getting stuck? I may not be able to help, but maybe general knowledge or just different eyes will help. Dec 29 21:16:23 You can't halt the board. What exactly does that mean? Dec 29 21:16:42 How deep is your knowledge of what is supposed to be happening when you halt the board? Dec 29 21:16:55 By not halt, I mean I get the following messages: Dec 29 21:16:56 > halt Dec 29 21:16:56 timed out while waiting for target halted Dec 29 21:16:56 Runtime error, file "command.c", line 456: Dec 29 21:16:56 > wait_halt Dec 29 21:16:56 timed out while waiting for target halted Dec 29 21:16:58 Runtime error, file "command.c", line 456: Dec 29 21:17:17 Where are these commands being issued? Dec 29 21:17:21 My knowledge is fairly limited with embedded debug. No formal training at my school, so I'm trying to teach myself. Dec 29 21:17:24 Telnet? Dec 29 21:18:27 I'm assuming the halt is telling the debug unit on the ARM to stop execution of the program. Dec 29 21:18:45 How are you issuing the halt command? Dec 29 21:19:03 gdb? Dec 29 21:19:03 I'm going through telnet. Dec 29 21:19:08 Ok. Dec 29 21:19:15 Can you do other things? Like mdw? Dec 29 21:19:49 mdw 0 256 Dec 29 21:19:57 would dump the first 256 words of memory to the screen. Dec 29 21:20:10 If that doesn't work, halt probably won't either. Dec 29 21:21:04 And it could just be something like running at too fast of a JTAG speed. Dec 29 21:21:07 I get a message about the target not being halted. Dec 29 21:21:39 How about "reset halt"? Dec 29 21:21:59 I'm gonna have to fire up openocd here and try to follow along. Dec 29 21:22:26 For the mdw 0 256 Dec 29 21:23:22 I get: BUG: unknown debug reason: 0xf Dec 29 21:23:49 Whoa. Dec 29 21:23:55 Then there are two more things output specifying two more bugs with unknown debug reasons. Dec 29 21:23:56 What interface? Dec 29 21:24:50 Here: Dec 29 21:24:51 openocd.cfg: http://pastebin.com/m12265adf Dec 29 21:24:51 board/olimex_sam9_l9260.cfg: http://pastebin.com/m327bb4b2 Dec 29 21:25:01 It's the Olimex JTAG Tiny Dec 29 21:25:27 The AT91SAM9260.cfg is the same as AT91SAM9260minimal.cfg in the current trunk Dec 29 21:26:21 I assume it goes without saying that you're sure that that is correct for your target board? Or is that what you're trying to figure out? Dec 29 21:27:08 At least I now know about the mww command. ;) Dec 29 21:27:24 I'm just guessing :) Dec 29 21:27:44 What is your target board? Dec 29 21:27:44 Actually, it's based off of the old AT91SAM9260.cfg which looked more like a board config file. Dec 29 21:27:53 Olimex SAM9-L9260 Dec 29 21:28:31 Ok, so pursuant to what I remember from the list, the minimal file is what you want, but if the board has any extra NAND FLASH, for example, it wouldn't be represented. Dec 29 21:28:36 That config and some initialization code from the AT91Bootstrap have been my guide for the mww commands Dec 29 21:29:13 I don't suppose the error messages tell you which command(s) is(are) throwing the errors. Dec 29 21:30:27 No, let me tweak the debug level Dec 29 21:31:18 I don't know if it's anything, but your board config sources target/at91sam9260.cfg, which, if I remember correctly, has extra board stuff that you don't want. Dec 29 21:32:08 No, I moved it in my version. I'll be submitting a patch once I get this going that includes moving the config files around for at91sam9260.cfg Dec 29 21:33:20 target/at91sam9260.cfg: http://pastebin.com/m739e05ef Dec 29 21:33:46 Ok, that looks about like what I expect. Dec 29 21:34:46 Answers my impending question about reset_config, jtag_nsrst_delay, and jtag_ntrst_delay, too. Though you still might find yourself playing with those at some point. Dec 29 21:36:28 So most of your board cfg is an initialization script. Do you get any errors while that is running? Do you know for a fact that it actually gets run? Dec 29 21:37:24 The reset-init event handler, that is. Dec 29 21:38:55 I don't know for sure if everything is hunky dorry in the init script. Dec 29 21:39:00 I think I might be getting errors when it runs when I do the 'reset init' command. Dec 29 21:39:43 An excellent point. Dec 29 21:41:09 You could comment out everything (or just not register the routine) and see if all of the errors go away. Then you could uncomment stuff until they start showing up again. I wish I knew a more scientific way of going about it, but without line numbers, I don't know if that's possible. Dec 29 21:42:04 Hence the labor intensive comment/uncomment method. Dec 29 21:42:15 That's a good idea. Dec 29 21:42:16 Actually, I think I just got it to halt :) Dec 29 21:42:24 Even better. :) Dec 29 21:42:28 I moved the interface config above the source of the board config Dec 29 21:43:11 Yeah. I don't think I've seen it mentioned, but it makes sense that the interface would have to be up before any target operation is expected to work. Dec 29 21:43:11 Memory dump works :) Dec 29 21:43:17 Good sign. Dec 29 21:44:17 I've just intinctively always specified the interface cfg before the board cfg, so have no firsthand experience with what happens when it's done backwards. Dec 29 21:45:50 Theoretically, it would still work. Stuff isn't supposed to be happening before an init command (or the last config file has been read). Dec 29 21:57:12 L_Deluxe, did you just leave and come back with a large chunk of the chat room participants? Dec 29 21:58:28 There appeared to be a net split. I saw the same thing involving you. Dec 29 21:58:45 Interesting. Dec 29 21:59:07 I knew such things happened on IRC, but hadn't actually _seen_ it before. Dec 29 21:59:24 It's an artifact of the distributed nature of IRC. Dec 29 21:59:31 You have any ideas about what to do with: Dec 29 21:59:32 TAP at91sam9260.cpu: Dec 29 21:59:32 value captured during scan didn't pass the requested check: Dec 29 21:59:32 captured: 0x0f check_value: 0x01 check_mask: 0x0f Dec 29 21:59:32 in_handler: w/o "in_value", mismatch in SIR Dec 29 21:59:36 I guess, crazy IRC. Dec 29 22:00:56 That usually means exactly what it says. It did an IR scan, expected to se 0x01 when masked with 0x0f, instead got 0x0f. Dec 29 22:01:21 If not for mdw working for you, I'd suspect a wiring problem. TDO always returning 1. Dec 29 22:01:58 Could just be that the hardware has gotten into a weird state where it isn't in the state that OpenOCD thinks it is. Dec 29 22:02:06 Well, it occurs when I try and look at and/or set values in memory mapped I/O devices. Dec 29 22:02:06 How deterministic is it? Dec 29 22:02:41 What do you mean? Dec 29 22:02:41 Does the next operation (of a different kind, of course) work? Dec 29 22:03:15 By deterministic, I mean does it happen every time you do something, or pseudorandomly. Dec 29 22:03:21 I guess not, I tried doing mdw 0 256 again and it listed same errors. Dec 29 22:04:27 I have the handicap of not being familiar with SAM9. Dec 29 22:04:34 Looks like it is only happening on memory hits Dec 29 22:04:50 But that tells us that it seems to be a mode thing. If mdw works, you do this thing, and mdw doesn't work afterward. Dec 29 22:05:36 That makes sense, the reg command works. Dec 29 22:05:58 Are those accesses in external memory? Dec 29 22:06:05 What about internal memory? Dec 29 22:06:17 Like mdw of FLASH. Dec 29 22:06:49 Stabbing in the dark, of course. Dec 29 22:08:18 I tried doing mdw 0 256, which is internal, and that's failing. Same thing happens when I try to read from specific memory from the internal SRAM Dec 29 22:08:58 Hmm. Ok, so we look at the thing that breaks mdw, then. Dec 29 22:09:17 Assuming you can do 2 mdw's in a row and they both work. Dec 29 22:09:35 I know the apostrophe there is wrong, but hopefully it conveys the right idea. Dec 29 22:11:03 Two mdw's work. Dec 29 22:11:11 And who cares about apostrophes ;) Dec 29 22:11:22 Good. Now what is the simplest operation that causes mdw to stop working? Dec 29 22:11:23 I reset power on the target Dec 29 22:13:18 You said something about memory hits. Dec 29 22:13:55 As in commands were working like jtag commands and the like, but any command to read or write memory areas weren't working. Dec 29 22:14:28 mdw works. Do you mean something else? Dec 29 22:14:36 Like mww Dec 29 22:15:04 So a memory write to, say, a harmless location in internal RAM will break everything? Dec 29 22:15:35 Most of the stuff you're writing to in that script is registers. Any of which could conceivably cause hardware operation changes. Dec 29 22:16:34 I can write memory. Dec 29 22:16:47 So then it's down to where you're writing. Dec 29 22:17:15 Yeah, I'm going to try and write to one of the configuration registers for one of the PIO controllers. Dec 29 22:17:31 Maybe turn an LED on :) Dec 29 22:17:50 Ok. That should be harmless. Particularly if you just set all of the pins to be inputs or turn on the pullups or something. Dec 29 22:18:02 Exactly. Dec 29 22:19:52 If it's like the SAM7, you should be able to just write to the port register if the IOW register is all zeroes. Dec 29 22:20:16 It's been awhile. A bit fuzzy on terminology. The principle is sound, though. Dec 29 22:21:04 In fact, that SAM9 is almost the same as SAM7 (it's supposed to be a possible upgrade path Dec 29 22:22:15 I figured that might be the case. Sure would be nice to have more than 64K of RAM. Dec 29 22:24:17 Actually, maybe they aren't so similar ;) The ARM9 only has like 8k of internal SRAM. Dec 29 22:24:27 Any more than that and you have to add external RAM. Dec 29 22:25:08 Whoa. The SAM7ES at least has something like 32K and lets you add external. No caches, though. Dec 29 22:25:42 But if I'm going to do external, I might as well go to SAM9. Dec 29 22:26:08 Yeah, and the internal ROM is not flash, so you have to have a bootloader or have a program that can fit in 4k of memory. Dec 29 22:26:30 And the program has to put out on external nand, nor or data flash. Dec 29 22:26:50 So the ROM just knows to try to boot from the external memories? Dec 29 22:27:17 I suppose that makes sense. Dec 29 22:27:29 Learned that one the hard way ;) Dec 29 22:27:29 By the way, the PIO control stuff is working great. I love blinking LEDs. Dec 29 22:27:34 Groovy. Dec 29 22:28:03 Yep, that's how the ARM9 boots, tries a few external locations, if it can't find anything, it will do the SAM-BA boot stuff. Dec 29 22:28:04 So it's pretty much some register that's not working quite the way you expect it to. As opposed to an OpenOCD issue. If my assumption is correct. Dec 29 22:28:45 Sure seems like it. I'm going to start doing the script comment / uncommenting to see if I can't get that going. Dec 29 22:28:53 I've dealt with SAM-BA on the SAM7S and 7X. Probably in more depth than most folks. Dec 29 22:29:15 I even mananged to get firmware to boot directly into SAM-BA, which is a feat. Dec 29 22:29:53 That's interesting, why did you need to do that? (if you can tell me ;)) Dec 29 22:31:15 For firmware upgrade. Issue a command to the running device to request it to re-enumerate as a SAM-BA device, which requires disabling the USB pullup before going into SAM-BA because SAM-BA on the 7X doesn't know about the USB pullup. Dec 29 22:31:31 The whole pullup thing is a zoo. Dec 29 22:31:39 With SAM-BA not grokking it. Dec 29 22:32:04 You'd think one can just clear GPNVM2 before doing a reset, but the clearing crashes the chip before you can reset. Dec 29 22:32:25 Besides, not clearing the bit potentially saves wear. Dec 29 22:33:37 My work in that department made it so that one can do firmware upgrades on the Make Controller without having to unplug the USB cable. Dec 29 22:35:45 Perhaps not so important if one is using JTAG, but the usual mode with the Make Controller is SAM-BA. Dec 29 22:37:45 lpc-p2148, openocd : flash write_image vrs lpc21isp. open ocd writes bits that don't execute where lpc21isp loads work :( any ideas? Dec 29 22:38:20 I'm of no help there, sorry. Dec 29 22:38:25 Sorry. Doesn't ring any bells with me. Dec 29 22:38:47 whats killing me is I had these working last spring :( Dec 29 22:39:26 I don't suppose there's any sort of MPU hardware involved. I don't know LPC. Dec 29 22:39:45 there is an mpu on the lpc2148 Dec 29 22:40:08 Maybe the load does sets an execute attribute that the write doesn't. Dec 29 22:40:16 Just guessing, of course. Dec 29 22:43:53 And assuming I even got anywhere close to properly understanding your enquiry. Dec 29 22:46:19 Perhaps, I don't know enough about what i'm doing to say. Dec 29 22:46:39 I guess I don't feel so bad, then. ;) Dec 29 22:47:12 I don't know enough about LPC to be able to extrapolate much beyond what I already have. Dec 29 22:47:36 We need more experts on this channel :) Dec 29 22:47:41 Yup. Dec 29 22:48:13 the last version of openocd I was using had load_image, now it has flash write_image I wonder if that has something to do with my troubles Dec 29 22:49:12 I got the impression it was just a rename. It could always be more, of course. More experts tend to hang out in the mail list. You could try a query there. Dec 29 22:50:42 Heck, some of them may have been directly involved in that change. Dec 29 22:51:19 where is the openocd mailing list anyway? Dec 29 22:51:29 Apparently, the reset-init event is not used on targets. Dec 29 22:51:39 That's according to the most recent docs (they need an update). Dec 29 22:51:55 What is it for, then? Dec 29 22:52:05 mgross, openocd-development@lists.berlios.de or some such Dec 29 22:52:22 https://lists.berlios.de/mailman/listinfo/openocd-development Dec 29 22:52:28 Took awhile, but I found it. Dec 29 22:53:00 secure connection failed Dec 29 22:53:22 Berlios has a wonky certificate. Dec 29 22:53:32 ok, I'm in now. Dec 29 22:55:09 L_Deluxe, it appears doing a reset init just puts OpenOCD in some state where it no longer takes memory instructions. Dec 29 22:55:21 My init script simply prints a string to the terminal. Dec 29 22:56:22 I know I've been able to do mdw while in reset init. Dec 29 22:56:39 Of course now I'm starting to doubt myself. Dec 29 22:56:52 mdw is not the only command failing. Dec 29 22:57:06 If I attempt a reset run, I get the same set of error output as with the mdw command. Dec 29 22:57:42 Do the TRST and SRST lines on your board work the way the config expects? Dec 29 22:58:21 I don't know what those lines are supposed to do :) Dec 29 22:58:41 The same issue happens if I reset halt. Dec 29 22:58:45 IIRC, the config expects them to both work and to do so independently. TRST going low is supposed to reset the TAP, and SRST going low is supposed to reset the target CPU. Dec 29 22:59:25 And there are delays that say how long to wait after deasserting the respective reset line before trying to do anything. Dec 29 23:00:38 Doing just a reset run followed by a halt command and mdw still works. Dec 29 23:02:03 I'm not sure what all the reset/halt/init stuff is. I think all the resets start with a reset run and the init and halt variants add something to that. There's apparently some history with that that I wasn't around for. Dec 29 23:02:40 Like maybe reset only did what reset run does now, and one explicitly had to add another command for halt or init. Dec 29 23:04:10 But the exact semantics... why I'd use one command over another or what I expect it to to in total, I haven't found out yet. Dec 29 23:04:50 I think the whole idea is that a reset init cause the reset-init event to happen, therefore you can do some initialization like in my board config. Dec 29 23:05:13 Reset halt is there for probably the same kind of reason. Dec 29 23:05:29 That would make sense. Though there may be a bigger picture. Dec 29 23:05:56 Just as another interesting point, when I do either a reset init or halt, I get an unknown error output that I don't get when I do a straight reset command Dec 29 23:07:59 That jives with my theory about the reset commands in that the halt or init operation might be causing the error. Dec 29 23:08:23 Or jibe or whatever that word is supposed to be; meaning to agree. Dec 29 23:09:03 I thought a jibe was like a cruel joke or something, though. Dec 29 23:09:47 Anyway, I may have reached the limit of how helpful I'm going to be able to be. It seems you've made some good progress, though. Dec 29 23:10:05 Just so you can see the debug level 3 output: http://pastebin.com/m3cd63002 Dec 29 23:11:27 It looks like the error happens after the second time the embeddedice tries to write out 0x5, for whatever reason. Dec 29 23:12:30 Where is that? Dec 29 23:13:08 Line 52? Dec 29 23:13:17 Yeah. Dec 29 23:13:19 I see the error now. Hmm. Dec 29 23:13:52 I know nothing of embededice. Dec 29 23:13:59 Is that your interface driver? Dec 29 23:14:45 It's a target. :\ Dec 29 23:16:18 And the error is coming from the arm926ejs target. Totally outside my area of knowledge. Dec 29 23:16:39 No, the driver is olimex-jtag or some such, but the ARM9 has embedded ice stuff, so maybe they are utilizing that. Dec 29 23:17:08 That error is there because its a callback from the target struct I believe. Dec 29 23:17:26 That doesn't really tell you where the error came from because you don't know what function called the call back. Dec 29 23:20:38 Yeah. **** ENDING LOGGING AT Tue Dec 30 02:59:56 2008