On Monday 25 January 2010, Alan Carvalho de Assis wrote: > Hi Dave, > > On 1/23/10, David Brownell <davi...@pacbell.net> wrote: > > On Monday 18 January 2010, Alan Carvalho de Assis wrote: > >> > >> What could I investigate now to fix this error? > > > > Unfortunately I think you're starting to hit some of the ways > > that the DAP code is ... a bit flakey. Especially with respect > > to how it handles errors reported by the DP or AP; it triggers > > faults a bit more often (and randomly) than I would expect, and > > the cleanup -- and mode selection -- looks a bit iffy to me. > > > > I attach a couple patches which I've been using, which might > > change things (or might not). If they help, good. ... > > > > If not, then there's something else you could build on top > > of these. ... > > > > It doesn't work. Even I putting the memaccess_tck cycles after > adi_jtag_dp_scan() I still getting the same error: > > $ telnet 127.0.0.1 4444 > Trying 127.0.0.1... > Connected to 127.0.0.1. > Escape character is '^]'. > Open On-Chip Debugger > > reset > JTAG tap: imx51.DAP tap/device found: 0x1ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x1) > TAP imx51.SDMA does not have IDCODE > JTAG tap: imx51.SJC tap/device found: 0x1190c01d (mfg: 0x00e, part: > 0x190c, ver: 0x1) > imx51.cpu: how to reset?
You should fix that. Is SRST wired? If not, try to find out how to issue a JTAG level reset ... maybe some SJC operations will do the job, that's a common approach. > Command handler execution failed > in procedure 'reset' called at file "command.c", line 647 > called at file "command.c", line 361 And from here on, I'd expect various failures caused by not having reset that core. (On top of any other issues!) > > halt > AHBAP Cached values: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0x54011080 > JTAG-DP OVERRUN - check clock or reduce jtag speed > Read MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011080 You're just going to have to find what causes that. As I noted, the DAP code is a bit iffy, especially with respect to fault handling. There are periodic reports of similar problems; they're not especially reproducible. Those are symptoms of timing-related bugs; but if you look at the code and spec, you'll probably end up scratching your head about various things. In the 0.5 series it's going to get some reworking to support SWD transport, which I think will likely shake out some of that flakiness. > > The OVERRUN error comes from throwing data at the MEM-AP > > faster than it can handle it. MEM-AP speed is a system > > specific issue. Exactly the sort of thing MX51 could very > > reasonably do differently from the other Cortex parts which > > now mostly work. (I'm not quite clear on how much of that > > is driven by the JTAG clock vs by whatever core clock your > > chip may be using.) There are two issues I'd wonder about: > > > > * First, whether the code is correct ... ergo the > > attached patches and that REVISIT comment. > > > > * Second, whether you need a different memaccess_tck > > value. > > > > The ADIv5 spec will be useful to sort out such issues. > > > > I tested memaccess_tck with small values as 8, 80, 100 and big values > as 100000. In all tests it returns same error message above. I just > noticied it delay a little more time to show this error msg when I use > 100000. OK, so the memaccess_tck issue doesn't seem to be the main problem here. It's clearly time for you to pull out the ADIv5 spec and start working with that and the code ... That's pretty low level work, and will often not be very straightforward. Prepare for some frustration, and be patient! - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
