On Tue, 19 Aug 2008 10:47:30 -0400, Nicolas Pitre wrote: > So far I've always been able to halt a Feroceon based board with no > flash content simply by holding the reset button while performing a halt > on the openocd console then quickly releasing the reset button. It > seems that the processor will happily halt right on the reset vector at > that point if DBGRQ is already asserted when it attempts to execute the > very first instruction after a reset.
Unless I miss my guess, on my board, the reset button is a simple GPIO line, so it does not perform this function. Is there some line i can trace that would provide a reset signal that could function this way? > The same should be doable by asserting the SRST signal but often the > JTAG cable (or the board design) doesn't route it properly if at all. Yes, it seems that part of the Marvell reference design prescribes improperly routing sRST. However, the troubles described at the links in my first post seem to indicate that this is only part of the story. There has to be a consistent way to halt the CPU across all Feroceon boards. On Tue, 19 Aug 2008 16:40:18 -0400, Nicolas Pitre wrote: > Normally, SRST and the reset button should be the same. TRST is separate > and affects only the debug interface logic. On some boards I have here, > nTRST is pulled low permanently and needs to have VCC applied to it for > the debug logic to operate (jumper required with those JTAG cables > without TRST signal). On my board, TRST appears to behave in the expected way, but sRST needs to have Vcc applied to operate JTAG. Or, am I missing something? _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
