| 04:47.51 | *** join/#openjtag dinomight (n=dnglaze@209.0.51.23) |
| 06:28.14 | *** join/#openjtag tjtag (n=tjtag@bhossman.user.matrix.farlep.net) |
| 07:01.27 | *** part/#openjtag dinomight (n=dnglaze@209.0.51.23) |
| 07:53.04 | *** join/#openjtag pleemans (n=toi@d51A49D31.access.telenet.be) |
| 10:39.14 | *** join/#openjtag dirk2 (n=dirk@p5B040A3C.dip0.t-ipconnect.de) |
| 10:51.40 | *** join/#openjtag Schorch1985 (n=georg@f048075207.adsl.alicedsl.de) |
| 17:11.58 | *** join/#openjtag dirk2 (n=dirk@p5B042479.dip0.t-ipconnect.de) |
| 17:30.52 | *** join/#openjtag tjtag (n=tjtag@bhossman.user.matrix.farlep.net) |
| 20:22.49 | *** join/#openjtag mgross (n=mgross@66.206.87.117) |
| 21:04.35 | *** part/#openjtag dirk2 (n=dirk@p5B042479.dip0.t-ipconnect.de) |
| 21:08.37 | *** join/#openjtag dinomight (n=dnglaze@209.0.51.23) |
| 21:09.07 | dinomight | Anybody listening out in the ether? |
| 21:10.07 | L_Deluxe | Yup. But not many talkers. |
| 21:10.45 | dinomight | Darn, I'm looking for some help understanding what could be wrong with my JTAG setup in OpenOCD. |
| 21:10.53 | dinomight | I can't halt the board, it just times out waiting for it. |
| 21:11.28 | L_Deluxe | Unfortunately, I'm not going to be able to be of much help. I'm a bit of a newbie. |
| 21:11.46 | dinomight | Darn, all the nubes hang out here (including me) |
| 21:11.56 | dinomight | Sorry, n00bs. |
| 21:12.09 | L_Deluxe | There is a lot more traffic on the list. |
| 21:12.16 | L_Deluxe | More than here, anyway. |
| 21:12.48 | L_Deluxe | Especially when I'm trying to get a patch accepted. ;) |
| 21:13.29 | dinomight | Yeah, the list at list has some talkers. |
| 21:14.01 | dinomight | 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 |
| 21:14.28 | L_Deluxe | It would be nice if there were a tutorial somewhere. Maybe there even is, but I haven't found it. |
| 21:15.03 | dinomight | Well, the docs have a full list of commands the OpenOCD handles, I just don't have a clue why they would fail. |
| 21:15.17 | dinomight | It could just be a misconfigured system or some such. |
| 21:15.57 | L_Deluxe | Where exactly are you getting stuck? I may not be able to help, but maybe general knowledge or just different eyes will help. |
| 21:16.23 | L_Deluxe | You can't halt the board. What exactly does that mean? |
| 21:16.42 | L_Deluxe | How deep is your knowledge of what is supposed to be happening when you halt the board? |
| 21:16.56 | dinomight | By not halt, I mean I get the following messages: |
| 21:16.56 | dinomight | > halt |
| 21:16.56 | dinomight | timed out while waiting for target halted |
| 21:16.56 | dinomight | Runtime error, file "command.c", line 456: |
| 21:16.56 | dinomight | > wait_halt |
| 21:16.56 | dinomight | timed out while waiting for target halted |
| 21:16.58 | dinomight | Runtime error, file "command.c", line 456: |
| 21:17.17 | L_Deluxe | Where are these commands being issued? |
| 21:17.21 | dinomight | My knowledge is fairly limited with embedded debug. No formal training at my school, so I'm trying to teach myself. |
| 21:17.24 | L_Deluxe | Telnet? |
| 21:18.27 | dinomight | I'm assuming the halt is telling the debug unit on the ARM to stop execution of the program. |
| 21:18.45 | L_Deluxe | How are you issuing the halt command? |
| 21:19.03 | L_Deluxe | gdb? |
| 21:19.03 | dinomight | I'm going through telnet. |
| 21:19.08 | L_Deluxe | Ok. |
| 21:19.15 | L_Deluxe | Can you do other things? Like mdw? |
| 21:19.49 | L_Deluxe | mdw 0 256 |
| 21:19.58 | L_Deluxe | would dump the first 256 words of memory to the screen. |
| 21:20.10 | L_Deluxe | If that doesn't work, halt probably won't either. |
| 21:21.04 | L_Deluxe | And it could just be something like running at too fast of a JTAG speed. |
| 21:21.07 | dinomight | I get a message about the target not being halted. |
| 21:21.39 | L_Deluxe | How about "reset halt"? |
| 21:21.59 | L_Deluxe | I'm gonna have to fire up openocd here and try to follow along. |
| 21:22.26 | dinomight | For the mdw 0 256 |
| 21:23.22 | dinomight | I get: BUG: unknown debug reason: 0xf |
| 21:23.49 | L_Deluxe | Whoa. |
| 21:23.55 | dinomight | Then there are two more things output specifying two more bugs with unknown debug reasons. |
| 21:23.56 | L_Deluxe | What interface? |
| 21:24.50 | dinomight | Here: |
| 21:24.51 | dinomight | openocd.cfg: http://pastebin.com/m12265adf |
| 21:24.51 | dinomight | board/olimex_sam9_l9260.cfg: http://pastebin.com/m327bb4b2 |
| 21:25.01 | dinomight | It's the Olimex JTAG Tiny |
| 21:25.27 | dinomight | The AT91SAM9260.cfg is the same as AT91SAM9260minimal.cfg in the current trunk |
| 21:26.21 | L_Deluxe | 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? |
| 21:27.08 | L_Deluxe | At least I now know about the mww command. ;) |
| 21:27.24 | dinomight | I'm just guessing :) |
| 21:27.44 | L_Deluxe | What is your target board? |
| 21:27.45 | dinomight | Actually, it's based off of the old AT91SAM9260.cfg which looked more like a board config file. |
| 21:27.53 | dinomight | Olimex SAM9-L9260 |
| 21:28.31 | L_Deluxe | 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. |
| 21:28.36 | dinomight | That config and some initialization code from the AT91Bootstrap have been my guide for the mww commands |
| 21:29.13 | L_Deluxe | I don't suppose the error messages tell you which command(s) is(are) throwing the errors. |
| 21:30.27 | dinomight | No, let me tweak the debug level |
| 21:31.18 | L_Deluxe | 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. |
| 21:32.08 | dinomight | 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 |
| 21:33.20 | dinomight | target/at91sam9260.cfg: http://pastebin.com/m739e05ef |
| 21:33.46 | L_Deluxe | Ok, that looks about like what I expect. |
| 21:34.46 | L_Deluxe | 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. |
| 21:36.28 | L_Deluxe | 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? |
| 21:37.24 | L_Deluxe | The reset-init event handler, that is. |
| 21:38.55 | dinomight | I don't know for sure if everything is hunky dorry in the init script. |
| 21:39.00 | dinomight | I think I might be getting errors when it runs when I do the 'reset init' command. |
| 21:39.43 | L_Deluxe | An excellent point. |
| 21:41.09 | L_Deluxe | 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. |
| 21:42.04 | L_Deluxe | Hence the labor intensive comment/uncomment method. |
| 21:42.15 | dinomight | That's a good idea. |
| 21:42.16 | dinomight | Actually, I think I just got it to halt :) |
| 21:42.24 | L_Deluxe | Even better. :) |
| 21:42.28 | dinomight | I moved the interface config above the source of the board config |
| 21:43.11 | L_Deluxe | 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. |
| 21:43.11 | dinomight | Memory dump works :) |
| 21:43.17 | L_Deluxe | Good sign. |
| 21:44.17 | L_Deluxe | 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. |
| 21:45.50 | L_Deluxe | Theoretically, it would still work. Stuff isn't supposed to be happening before an init command (or the last config file has been read). |
| 21:50.18 | *** join/#openjtag wookey_ (n=wookey@stoneboat.aleph1.co.uk) [NETSPLIT VICTIM] |
| 21:50.21 | *** join/#openjtag dinomight (n=dnglaze@209.0.51.23) [NETSPLIT VICTIM] |
| 21:50.21 | *** join/#openjtag mgross (n=mgross@66.206.87.117) [NETSPLIT VICTIM] |
| 21:50.21 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) [NETSPLIT VICTIM] |
| 21:50.21 | *** join/#openjtag toi (n=pleemans@d5153128F.access.telenet.be) [NETSPLIT VICTIM] |
| 21:57.12 | dinomight | L_Deluxe, did you just leave and come back with a large chunk of the chat room participants? |
| 21:58.28 | L_Deluxe | There appeared to be a net split. I saw the same thing involving you. |
| 21:58.45 | dinomight | Interesting. |
| 21:59.07 | L_Deluxe | I knew such things happened on IRC, but hadn't actually _seen_ it before. |
| 21:59.24 | L_Deluxe | It's an artifact of the distributed nature of IRC. |
| 21:59.31 | dinomight | You have any ideas about what to do with: |
| 21:59.32 | dinomight | TAP at91sam9260.cpu: |
| 21:59.32 | dinomight | value captured during scan didn't pass the requested check: |
| 21:59.32 | dinomight | captured: 0x0f check_value: 0x01 check_mask: 0x0f |
| 21:59.32 | dinomight | in_handler: w/o "in_value", mismatch in SIR |
| 21:59.36 | dinomight | I guess, crazy IRC. |
| 22:00.56 | L_Deluxe | That usually means exactly what it says. It did an IR scan, expected to se 0x01 when masked with 0x0f, instead got 0x0f. |
| 22:01.21 | L_Deluxe | If not for mdw working for you, I'd suspect a wiring problem. TDO always returning 1. |
| 22:01.58 | L_Deluxe | Could just be that the hardware has gotten into a weird state where it isn't in the state that OpenOCD thinks it is. |
| 22:02.06 | dinomight | Well, it occurs when I try and look at and/or set values in memory mapped I/O devices. |
| 22:02.06 | L_Deluxe | How deterministic is it? |
| 22:02.41 | dinomight | What do you mean? |
| 22:02.42 | L_Deluxe | Does the next operation (of a different kind, of course) work? |
| 22:03.15 | L_Deluxe | By deterministic, I mean does it happen every time you do something, or pseudorandomly. |
| 22:03.21 | dinomight | I guess not, I tried doing mdw 0 256 again and it listed same errors. |
| 22:04.28 | L_Deluxe | I have the handicap of not being familiar with SAM9. |
| 22:04.34 | dinomight | Looks like it is only happening on memory hits |
| 22:04.50 | L_Deluxe | 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. |
| 22:05.36 | dinomight | That makes sense, the reg command works. |
| 22:05.58 | L_Deluxe | Are those accesses in external memory? |
| 22:06.05 | L_Deluxe | What about internal memory? |
| 22:06.17 | L_Deluxe | Like mdw of FLASH. |
| 22:06.49 | L_Deluxe | Stabbing in the dark, of course. |
| 22:08.18 | dinomight | 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 |
| 22:08.58 | L_Deluxe | Hmm. Ok, so we look at the thing that breaks mdw, then. |
| 22:09.17 | L_Deluxe | Assuming you can do 2 mdw's in a row and they both work. |
| 22:09.35 | L_Deluxe | I know the apostrophe there is wrong, but hopefully it conveys the right idea. |
| 22:11.03 | dinomight | Two mdw's work. |
| 22:11.11 | dinomight | And who cares about apostrophes ;) |
| 22:11.22 | L_Deluxe | Good. Now what is the simplest operation that causes mdw to stop working? |
| 22:11.23 | dinomight | I reset power on the target |
| 22:13.19 | L_Deluxe | You said something about memory hits. |
| 22:13.55 | dinomight | As in commands were working like jtag commands and the like, but any command to read or write memory areas weren't working. |
| 22:14.28 | L_Deluxe | mdw works. Do you mean something else? |
| 22:14.36 | dinomight | Like mww |
| 22:15.04 | L_Deluxe | So a memory write to, say, a harmless location in internal RAM will break everything? |
| 22:15.35 | L_Deluxe | Most of the stuff you're writing to in that script is registers. Any of which could conceivably cause hardware operation changes. |
| 22:16.34 | dinomight | I can write memory. |
| 22:16.47 | L_Deluxe | So then it's down to where you're writing. |
| 22:17.15 | dinomight | Yeah, I'm going to try and write to one of the configuration registers for one of the PIO controllers. |
| 22:17.31 | dinomight | Maybe turn an LED on :) |
| 22:17.50 | L_Deluxe | Ok. That should be harmless. Particularly if you just set all of the pins to be inputs or turn on the pullups or something. |
| 22:18.02 | dinomight | Exactly. |
| 22:19.52 | L_Deluxe | If it's like the SAM7, you should be able to just write to the port register if the IOW register is all zeroes. |
| 22:20.16 | L_Deluxe | It's been awhile. A bit fuzzy on terminology. The principle is sound, though. |
| 22:21.04 | dinomight | In fact, that SAM9 is almost the same as SAM7 (it's supposed to be a possible upgrade path |
| 22:22.15 | L_Deluxe | I figured that might be the case. Sure would be nice to have more than 64K of RAM. |
| 22:24.17 | dinomight | Actually, maybe they aren't so similar ;) The ARM9 only has like 8k of internal SRAM. |
| 22:24.27 | dinomight | Any more than that and you have to add external RAM. |
| 22:25.08 | L_Deluxe | Whoa. The SAM7ES at least has something like 32K and lets you add external. No caches, though. |
| 22:25.42 | L_Deluxe | But if I'm going to do external, I might as well go to SAM9. |
| 22:26.08 | dinomight | 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. |
| 22:26.30 | dinomight | And the program has to put out on external nand, nor or data flash. |
| 22:26.50 | L_Deluxe | So the ROM just knows to try to boot from the external memories? |
| 22:27.17 | L_Deluxe | I suppose that makes sense. |
| 22:27.29 | dinomight | Learned that one the hard way ;) |
| 22:27.29 | dinomight | By the way, the PIO control stuff is working great. I love blinking LEDs. |
| 22:27.34 | L_Deluxe | Groovy. |
| 22:28.03 | dinomight | 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. |
| 22:28.04 | L_Deluxe | 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. |
| 22:28.45 | dinomight | Sure seems like it. I'm going to start doing the script comment / uncommenting to see if I can't get that going. |
| 22:28.53 | L_Deluxe | I've dealt with SAM-BA on the SAM7S and 7X. Probably in more depth than most folks. |
| 22:29.15 | L_Deluxe | I even mananged to get firmware to boot directly into SAM-BA, which is a feat. |
| 22:29.53 | dinomight | That's interesting, why did you need to do that? (if you can tell me ;)) |
| 22:31.15 | L_Deluxe | 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. |
| 22:31.31 | L_Deluxe | The whole pullup thing is a zoo. |
| 22:31.39 | L_Deluxe | With SAM-BA not grokking it. |
| 22:32.06 | L_Deluxe | You'd think one can just clear GPNVM2 before doing a reset, but the clearing crashes the chip before you can reset. |
| 22:32.25 | L_Deluxe | Besides, not clearing the bit potentially saves wear. |
| 22:32.38 | *** join/#openjtag mgross (n=mgross@66.206.87.117) |
| 22:33.37 | L_Deluxe | 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. |
| 22:35.45 | L_Deluxe | Perhaps not so important if one is using JTAG, but the usual mode with the Make Controller is SAM-BA. |
| 22:37.45 | mgross | lpc-p2148, openocd : flash write_image vrs lpc21isp. open ocd writes bits that don't execute where lpc21isp loads work :( any ideas? |
| 22:38.20 | dinomight | I'm of no help there, sorry. |
| 22:38.25 | L_Deluxe | Sorry. Doesn't ring any bells with me. |
| 22:38.47 | mgross | whats killing me is I had these working last spring :( |
| 22:39.26 | L_Deluxe | I don't suppose there's any sort of MPU hardware involved. I don't know LPC. |
| 22:39.45 | mgross | there is an mpu on the lpc2148 |
| 22:40.08 | L_Deluxe | Maybe the load does sets an execute attribute that the write doesn't. |
| 22:40.16 | L_Deluxe | Just guessing, of course. |
| 22:43.53 | L_Deluxe | And assuming I even got anywhere close to properly understanding your enquiry. |
| 22:46.19 | mgross | Perhaps, I don't know enough about what i'm doing to say. |
| 22:46.39 | L_Deluxe | I guess I don't feel so bad, then. ;) |
| 22:47.12 | L_Deluxe | I don't know enough about LPC to be able to extrapolate much beyond what I already have. |
| 22:47.37 | dinomight | We need more experts on this channel :) |
| 22:47.41 | L_Deluxe | Yup. |
| 22:48.13 | mgross | 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 |
| 22:49.12 | L_Deluxe | 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. |
| 22:50.42 | L_Deluxe | Heck, some of them may have been directly involved in that change. |
| 22:51.19 | mgross | where is the openocd mailing list anyway? |
| 22:51.29 | dinomight | Apparently, the reset-init event is not used on targets. |
| 22:51.39 | dinomight | That's according to the most recent docs (they need an update). |
| 22:51.55 | L_Deluxe | What is it for, then? |
| 22:52.05 | dinomight | mgross, openocd-development@lists.berlios.de or some such |
| 22:52.23 | L_Deluxe | https://lists.berlios.de/mailman/listinfo/openocd-development |
| 22:52.28 | L_Deluxe | Took awhile, but I found it. |
| 22:53.00 | mgross | secure connection failed |
| 22:53.22 | L_Deluxe | Berlios has a wonky certificate. |
| 22:53.32 | mgross | ok, I'm in now. |
| 22:55.09 | dinomight | L_Deluxe, it appears doing a reset init just puts OpenOCD in some state where it no longer takes memory instructions. |
| 22:55.21 | dinomight | My init script simply prints a string to the terminal. |
| 22:56.22 | L_Deluxe | I know I've been able to do mdw while in reset init. |
| 22:56.39 | L_Deluxe | Of course now I'm starting to doubt myself. |
| 22:56.52 | dinomight | mdw is not the only command failing. |
| 22:57.06 | dinomight | If I attempt a reset run, I get the same set of error output as with the mdw command. |
| 22:57.43 | L_Deluxe | Do the TRST and SRST lines on your board work the way the config expects? |
| 22:58.21 | dinomight | I don't know what those lines are supposed to do :) |
| 22:58.41 | dinomight | The same issue happens if I reset halt. |
| 22:58.45 | L_Deluxe | 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. |
| 22:59.25 | L_Deluxe | And there are delays that say how long to wait after deasserting the respective reset line before trying to do anything. |
| 23:00.38 | dinomight | Doing just a reset run followed by a halt command and mdw still works. |
| 23:02.03 | L_Deluxe | 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. |
| 23:02.40 | L_Deluxe | Like maybe reset only did what reset run does now, and one explicitly had to add another command for halt or init. |
| 23:04.10 | L_Deluxe | 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. |
| 23:04.50 | dinomight | 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. |
| 23:05.13 | dinomight | Reset halt is there for probably the same kind of reason. |
| 23:05.29 | L_Deluxe | That would make sense. Though there may be a bigger picture. |
| 23:05.56 | dinomight | 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 |
| 23:07.59 | L_Deluxe | That jives with my theory about the reset commands in that the halt or init operation might be causing the error. |
| 23:08.23 | L_Deluxe | Or jibe or whatever that word is supposed to be; meaning to agree. |
| 23:09.03 | L_Deluxe | I thought a jibe was like a cruel joke or something, though. |
| 23:09.47 | L_Deluxe | 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. |
| 23:10.05 | dinomight | Just so you can see the debug level 3 output: http://pastebin.com/m3cd63002 |
| 23:11.27 | dinomight | It looks like the error happens after the second time the embeddedice tries to write out 0x5, for whatever reason. |
| 23:12.30 | L_Deluxe | Where is that? |
| 23:13.08 | L_Deluxe | Line 52? |
| 23:13.17 | dinomight | Yeah. |
| 23:13.19 | L_Deluxe | I see the error now. Hmm. |
| 23:13.52 | L_Deluxe | I know nothing of embededice. |
| 23:13.59 | L_Deluxe | Is that your interface driver? |
| 23:14.45 | L_Deluxe | It's a target. :\ |
| 23:16.18 | L_Deluxe | And the error is coming from the arm926ejs target. Totally outside my area of knowledge. |
| 23:16.39 | dinomight | No, the driver is olimex-jtag or some such, but the ARM9 has embedded ice stuff, so maybe they are utilizing that. |
| 23:17.08 | dinomight | That error is there because its a callback from the target struct I believe. |
| 23:17.26 | dinomight | That doesn't really tell you where the error came from because you don't know what function called the call back. |
| 23:20.38 | L_Deluxe | Yeah. |
| 23:56.31 | *** join/#openjtag mgross (n=mgross@66.206.87.117) |