On Wed, Oct 14, 2009 at 7:01 AM, michal smulski <[email protected]> wrote: > > arm11 has a bug in that you cannot at the same time assert srst to the > arm11 core and access its JTAG logic. Asserting srst will disable TAP > logic.
So SRST gates JTAG.... What I'm also unclear about is whether SRST issues a tms sequence or somehow screws up the TAP state. srst pulls trst is different from simply messing up the tap state, which can be corrrected by a tms sequence. tms sequence means clocking out >5 tms and resetting tap to TAP_RESET. > My guess is that flops' reset pin in JTAG core are connected to srst. flops? > It is unclear to me how long you have to wait after reset before > accessing JTAG. > It looks like srst puts JTAG logic into power-on-reset state. power-on-reset is ambigous. There is lots of electronics on an iMX351 and which of those will be go into power-on-reset upon asserting srst? E.g. the iMX351 can get into a state where asserting/deasserting srst will not give me the RedBoot output on the serial, whereas I can still debug RedBoot. To me this is indicative that there is some part of the peripherals that is not being reset. > There is another bug in the arm11 core. When you generate an access to > external logic (for example ddr controller via AHB bus) and that block > is not configured (perhaps it is still held in reset), that transaction > will never complete. This will hang arm11 core but it will also hang > JTAG controller. Nothing, short of srst assertion will bring it out of > this. so asserting srst from the arm11 code is required.... > Hope this helps. Every bit helps! Getting arm11 reset code "just right" isn't going to be easy... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
