Re: [Openocd-development] Idea on dr/irscan command handling
On Monday 15 June 2009, Laurent Gauch wrote: It could be don't care, but it will be better to fix/drive TMS at '1'. Putting the JTAG TAP in RESET State. After JTAG power domain sequence (100x TCK TMS '1'), we will enter in JTAG Startup sequence (Minimum of 5x TCK with TMS at '1'). Or just make the TLR entry use 100 clocks not just 5. :) It seems there are multiple ways that TLR can be entered though; there's also TRST. It may be important to do a better job of tracking that, and ensuring that entering TLR is always followed immediately by N clocks with TMS high. That will call for a bit of code re-factoring. Seems like a post-0.2.0 change. After what we can start the Debug Startup sequence. (drive EMU0, EMU1, TRST, SRST ...). The EMU0/EMU1 bit would be tricky, given that OpenOCD doesn't currently understand those signals ... But yes, such support would be good someday. I understand that some non-default combination (just one of them pulled low by the JTAG adapter, I think) triggers wait-in-reset on some chips. - Dave Finally, we will enter in the Debug sequencess ;-) Regards, Laurent htpp://www.amontec.com Amontec JTAGkey (Full-Speed USB JTAG Adapter 6MHz TCK) Amontec JTAGkey2 (High-Speed USB JTAG Adapter 30MHz TCK) From my experiments, it appears to be don't-care for TMS. They just need 100 TCK pulses to flip the bit to enable the JTAG power domain. -- Rick Altherr kc8apf at kc8apf.net https://lists.berlios.de/mailman/listinfo/openocd-development He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned On Jun 10, 2009, at 1:28 PM, David Brownell wrote: / On Wednesday 10 June 2009, David Brownell wrote: // http://tiexpressdsp.com/index.php/ICEPICK // // The how to add devices to an ICEpick-C scan chain highlights // one point: the JRC commands to add the ARM (and, for DaVinci, // the ETB) to the scan chain must be done each time the TAPs go // to the RESET state (via TMS or nTRST). // // Hmm, and also: // // Before starting the debugger, the debug power domain must // be activated by applying a minimum of 100 (free running) // TCK pulses to the device after nTRST is pulled high. // // It's not clear whether that means TMS high, low, or don't-care. // Does anyone know? // // If it's not TMS low then I wonder if it's practical to make normal // startup processing -- or entry to JTAG's RESET state -- always do // that. Could it hurt anything? // // If TMS low works then it's a bit sad that JRCs aren't targets. // Else the reset-deassert-post handler could just runtest 100; // those handlers don't kick in for TAPs, just targets. (Which // seems like a non-useful restriction, FWIW.) // // - Dave // ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Idea on dr/irscan command handling
It could be don't care, but it will be better to fix/drive TMS at '1'. Putting the JTAG TAP in RESET State. After JTAG power domain sequence (100x TCK TMS '1'), we will enter in JTAG Startup sequence (Minimum of 5x TCK with TMS at '1'). After what we can start the Debug Startup sequence. (drive EMU0, EMU1, TRST, SRST ...). Finally, we will enter in the Debug sequencess ;-) Regards, Laurent htpp://www.amontec.com Amontec JTAGkey (Full-Speed USB JTAG Adapter 6MHz TCK) Amontec JTAGkey2 (High-Speed USB JTAG Adapter 30MHz TCK) From my experiments, it appears to be don't-care for TMS. They just need 100 TCK pulses to flip the bit to enable the JTAG power domain. -- Rick Altherr kc8apf at kc8apf.net https://lists.berlios.de/mailman/listinfo/openocd-development He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned On Jun 10, 2009, at 1:28 PM, David Brownell wrote: / On Wednesday 10 June 2009, David Brownell wrote: // http://tiexpressdsp.com/index.php/ICEPICK // // The how to add devices to an ICEpick-C scan chain highlights // one point: the JRC commands to add the ARM (and, for DaVinci, // the ETB) to the scan chain must be done each time the TAPs go // to the RESET state (via TMS or nTRST). // // Hmm, and also: // // Before starting the debugger, the debug power domain must // be activated by applying a minimum of 100 (free running) // TCK pulses to the device after nTRST is pulled high. // // It's not clear whether that means TMS high, low, or don't-care. // Does anyone know? // // If it's not TMS low then I wonder if it's practical to make normal // startup processing -- or entry to JTAG's RESET state -- always do // that. Could it hurt anything? // // If TMS low works then it's a bit sad that JRCs aren't targets. // Else the reset-deassert-post handler could just runtest 100; // those handlers don't kick in for TAPs, just targets. (Which // seems like a non-useful restriction, FWIW.) // // - Dave // // ___ // Openocd-development mailing list // Openocd-development at lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development // https://lists.berlios.de/mailman/listinfo/openocd-development / ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
On Tuesday 09 June 2009, Magnus Lundin wrote: The type of target/tap initialisation that needs dr/ir scans to setup the jtag chain and controller are run before the target can be examined. The type of target initialisations that sets memory mapped registers with mww are not affected by polling- Polls, and many other commands, are not sent to targets that has not been examined. So the initial dr/ir scans are not interrupted. If we want to do manual dr/ir scans after the target has been setup, initialised and examined, the it is reasonable that we have to use poll off. So what I think we need is a delayed target examination, something like when defining a target we set a flag -delay_examine to signal that more setup must be done before the targtet can be examined with arp_examine. And presumably you've seen something like the info at this page: http://tiexpressdsp.com/index.php/ICEPICK The how to add devices to an ICEpick-C scan chain highlights one point: the JRC commands to add the ARM (and, for DaVinci, the ETB) to the scan chain must be done each time the TAPs go to the RESET state (via TMS or nTRST). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
On Wednesday 10 June 2009, David Brownell wrote: http://tiexpressdsp.com/index.php/ICEPICK The how to add devices to an ICEpick-C scan chain highlights one point: the JRC commands to add the ARM (and, for DaVinci, the ETB) to the scan chain must be done each time the TAPs go to the RESET state (via TMS or nTRST). Hmm, and also: Before starting the debugger, the debug power domain must be activated by applying a minimum of 100 (free running) TCK pulses to the device after nTRST is pulled high. It's not clear whether that means TMS high, low, or don't-care. Does anyone know? If it's not TMS low then I wonder if it's practical to make normal startup processing -- or entry to JTAG's RESET state -- always do that. Could it hurt anything? If TMS low works then it's a bit sad that JRCs aren't targets. Else the reset-deassert-post handler could just runtest 100; those handlers don't kick in for TAPs, just targets. (Which seems like a non-useful restriction, FWIW.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
From my experiments, it appears to be don't-care for TMS. They just need 100 TCK pulses to flip the bit to enable the JTAG power domain. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned On Jun 10, 2009, at 1:28 PM, David Brownell wrote: On Wednesday 10 June 2009, David Brownell wrote: http://tiexpressdsp.com/index.php/ICEPICK The how to add devices to an ICEpick-C scan chain highlights one point: the JRC commands to add the ARM (and, for DaVinci, the ETB) to the scan chain must be done each time the TAPs go to the RESET state (via TMS or nTRST). Hmm, and also: Before starting the debugger, the debug power domain must be activated by applying a minimum of 100 (free running) TCK pulses to the device after nTRST is pulled high. It's not clear whether that means TMS high, low, or don't-care. Does anyone know? If it's not TMS low then I wonder if it's practical to make normal startup processing -- or entry to JTAG's RESET state -- always do that. Could it hurt anything? If TMS low works then it's a bit sad that JRCs aren't targets. Else the reset-deassert-post handler could just runtest 100; those handlers don't kick in for TAPs, just targets. (Which seems like a non-useful restriction, FWIW.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
Øyvind Harboe wrote: Q: should dr/irscan throw an error if polling is enabled? OpenOCD does background polling based on a timer, so two consecutive ir/drscan commands could see other JTAG operations intervening, wreaking havoc. Targets such as the OMAP needs to run a sequence of jtag commands uninterrupted. Some ideas: - implementations must start such sequences by poll off and end them with poll on. Ugly, but supported today. - define a wrapper tcl proc that handles reading the current polling state, turning off polling, executing a sequence of commands and then restoring the polling status regardless of whether an exception was thrown or not. Writing such a wrapper is easy. - make all reset event scripts run with background events disabled. The ir/drscan also lacks the ability to return the data clocked in, it does not support longer than 32 bits scans, and there is no statemove/pathmove command + a raft of other shortcomings of these commands, but that's really an independant issue. I do not think this is so bad really: The type of target/tap initialisation that needs dr/ir scans to setup the jtag chain and controller are run before the target can be examined. The type of target initialisations that sets memory mapped registers with mww are not affected by polling- Polls, and many other commands, are not sent to targets that has not been examined. So the initial dr/ir scans are not interrupted. If we want to do manual dr/ir scans after the target has been setup, initialised and examined, the it is reasonable that we have to use poll off. So what I think we need is a delayed target examination, something like when defining a target we set a flag -delay_examine to signal that more setup must be done before the targtet can be examined with arp_examine. My två öre, regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
On Tue, Jun 9, 2009 at 7:37 PM, David Brownelldavi...@pacbell.net wrote: On Tuesday 09 June 2009, Ųyvind Harboe wrote: - make all reset event scripts run with background events disabled. Surprises me that's not already the case... Note that output of poll doesn't say whether the timer thing is active. So it's pretty much hidden. Also, that the documentation doesn't mention *why* this background activity might be desired. Is there a better reason than that's how it's always been done? An example of why this was done in the past is that when you type resume, you want to get a message when the target halts. So when the command line is in idle, you poll. However, I've given some thought to when polling should be active and perhaps we have gotten it wrong and *no* polling should be done. Instead we could define that a telnet session that shows a prompt is *NOT* idle, but rather that a telnet prompt waiting for input is polling the *active* target. So during execution of a command or when the telnet is closed and only gdb is running, there is no background polling. I'm not a great fan of numerous handlers that listens for events(control inversion) and invokes fn's that somehow have to figure out if it is time to do something or other... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
On Tuesday 09 June 2009, Øyvind Harboe wrote: On Tue, Jun 9, 2009 at 7:37 PM, David Brownelldavi...@pacbell.net wrote: On Tuesday 09 June 2009, Ųyvind Harboe wrote: - make all reset event scripts run with background events disabled. Surprises me that's not already the case... Note that output of poll doesn't say whether the timer thing is active. So it's pretty much hidden. Also, that the documentation doesn't mention *why* this background activity might be desired. Is there a better reason than that's how it's always been done? An example of why this was done in the past is that when you type resume, you want to get a message when the target halts. So when the command line is in idle, you poll. Makes sense. However, I've given some thought to when polling should be active and perhaps we have gotten it wrong and *no* polling should be done. Instead we could define that a telnet session that shows a prompt is *NOT* idle, but rather that a telnet prompt waiting for input is polling the *active* target. So during execution of a command or when the telnet is closed and only gdb is running, there is no background polling. That's what I would expect. Only poll if the event could happen, and there's a listener that cares about it. And the only event of interest seems to be transitioning from a running or debug-running state ... to something else. With the only listeners being the TCL shell, or in some cases GDB (when a breakpoint or watchpoint fires). I'm not a great fan of numerous handlers that listens for events(control inversion) and invokes fn's that somehow have to figure out if it is time to do something or other... Sometimes async/event-driven code is required. I have a similar aversion to code that tries to model async realities in synchronous terms. ;) In this case there's true concurrency except when all the targets are halted. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
And the only event of interest seems to be transitioning from a running or debug-running state ... to something else. With the only listeners being the TCL shell, or in some cases GDB (when a breakpoint or watchpoint fires). There are other events: - the target can send messages via DCC - power outage(which drivers can detect if they support it) - srst assert/deassert detection. srst can be asserted by other devices than JTAG, e.g. the CPU itself. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
On Tuesday 09 June 2009, Øyvind Harboe wrote: And the only event of interest seems to be transitioning from a running or debug-running state ... to something else. With the only listeners being the TCL shell, or in some cases GDB (when a breakpoint or watchpoint fires). There are other events: - the target can send messages via DCC - power outage(which drivers can detect if they support it) - srst assert/deassert detection. srst can be asserted by other devices than JTAG, e.g. the CPU itself. Good info. I'll supply a doc update to highlight and explain this polling activity ... I think I have good answers for my questions now. :) Same update will make poll output say if the periodic polling is active. There are also various JTAG connector standards which support GPIO-ish event channels (potentially bidirectional). Atmel's Nexus connectors include event in and out signals. TI uses EMU0 and EMU1 ... and on some connectors I think EMU2..EMU5. And I think I've seen this on other hardware too. Sometimes that seems to be called instrumentation support, with some of the signals used to flag e.g. trace buffer has overflowed or whatever else might merit immediate debugger attention. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Idea on dr/irscan command handling
Having thought of the problem with asynchronous stuff like DCC feedback, I'm now leaning towards defining a macro that wraps dr/irscan sequences with poll off/on. I'm thinking that the entire reset procedure should be w/polling off too. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
