Re: [Openocd-development] 0.3 anyone?
David Brownell pisze: Not clear on the status of those LPC2xxx things. I think they'd be ready to go if they didn't set up bogus clock rates... All I'm doing is waiting for your suggestion to solve the bug (for me that's not a bug [; ) - as I really see no other way for that stuff to work without another 7 levels of abstraction just because clock rate doesn't belong to target... Unfortunately - for LPC2xxx it does. If the scripts are supposed to be user friendly, then I see no other way, as every other suggestion is harder than the method I suggested: changing the files - just like now - but this time the frequency is visible and described. So what should I do? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Saturday 26 September 2009, Freddie Chopin wrote: David Brownell pisze: Not clear on the status of those LPC2xxx things. I think they'd be ready to go if they didn't set up bogus clock rates... All I'm doing is waiting for your suggestion to solve the bug (for me that's not a bug [; ) - as I really see no other way for that stuff to work without another 7 levels of abstraction just because clock rate doesn't belong to target... Unfortunately - for LPC2xxx it does. I don't see what you're getting at. I looked at the datasheet for the first chip in your patch, which says crystals can have quite a range outside of the single 12 MHz option you provided. Fixing this doesn't involve 7 levels of abstraction. Just give the crystal setting the kind of if it's not provided check you give other variables ... but error if it's not set. If the scripts are supposed to be user friendly, then I see no other way, as every other suggestion is harder than the method I suggested: changing the files - just like now - but this time the frequency is visible and described. So what should I do? Take those clock rate settings out of all the target-specific files; probably leave a one-line comment listing the variable name and saying the caller *must* set it appropriately for their target board. Add a few lines to the shared setup code which tests for that variable. If not set, emit a diagnostic and fail. If set, use it the way you now use it ... and to configure the JTAG clock rate. I think there will need to be some LPC2xxx-specific advice somewhere, probably the user's guide. If you like, I can draft it. It'd probably take the form of a sample openocd.cfg file for someone with a custom LPC-based board, with the three lines (source interface, set clock, source target/lpc); and the suggestion that debug-oriented LPC builds add a delay right after startup and before starting the clock, allowing JTAG to attach before any real code runs. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Mon, 2009-09-21 at 10:23 -0700, David Brownell wrote: On Monday 21 September 2009, Øyvind Harboe wrote: 0.3 anyone? There's lots of good progress since 0.2. Does anyone have a bunch of stuff that will be completed in the near future? [snip] How about we aim to get remaining significant updates in by Friday, and use next week as the first all-bugfixes QA cycle? This week could, for most folk, be a primarily-bugfixing cycle. Test the code on your boards, report and resolve the bugs... It's Friday. How are things looking? Do we want to have an -rc release process this time around? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Monday 21 September 2009, Øyvind Harboe wrote: Could he be repairing a bug in the driver where the driver does not track the JTAG state correctly after a srst that pulls trst? Could be; I hope he reports what's up ... :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
0.3 anyone? There's lots of good progress since 0.2. Does anyone have a bunch of stuff that will be completed in the near future? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
Øyvind Harboe pisze: Does anyone have a bunch of stuff that will be completed in the near future? How about that new LPC2xxx cfg files layout? With a bit of investigation the reset init should be working, or that can be left for future, as now this script is not fully functional either... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
Hi,
I had problems with the reset init on LPC2478, too. I didn't analyze it
deeply, but I noticed this problem:
OpenOCD reported that it couldn't halt the target. With debug on, I got the
impression that the EmbeddedICE had been programmed for a break before the
final SRST/TRST happened. There was an attempt to reprogram it afterwards, but
that didn't seem to be complete.
I've added a call to jtag_add_tlr(), and that solved it for me.
All relevant EmbeddedICE registers are now reprogrammed.
It looks like there's some internal state which didn't notice that the target
hardware got a reset. Seems reasonable to me to have the TAP reset call here,
but I'm not an expert...
Regards,
Rolf
Index: src/target/arm7_9_common.c
===
--- src/target/arm7_9_common.c (revision 2731)
+++ src/target/arm7_9_common.c (working copy)
@@ -1105,6 +1105,9 @@
if (target-reset_halt (jtag_reset_config RESET_SRST_PULLS_TRST)
!= 0)
{
LOG_WARNING(srst pulls trst - can not reset into halted mode.
Issuing halt after reset.);
+
+ jtag_add_tlr();
+
/* set up embedded ice registers again */
if ((retval = target_examine_one(target)) != ERROR_OK)
return retval;
--- Freddie Chopin freddie_cho...@op.pl schrieb am Mo, 21.9.2009:
Von: Freddie Chopin freddie_cho...@op.pl
Betreff: Re: [Openocd-development] 0.3 anyone?
An: Øyvind Harboe oyvind.har...@zylin.com
CC: openocd-development@lists.berlios.de
Datum: Montag, 21. September 2009, 19:04
Øyvind Harboe pisze:
Does anyone have a bunch of stuff that will be
completed in the near future?
How about that new LPC2xxx cfg files layout?
With a bit of investigation the reset init should be
working, or that
can be left for future, as now this script is not fully
functional either...
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
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] 0.3 anyone?
On Mon, Sep 21, 2009 at 7:04 PM, Freddie Chopin freddie_cho...@op.pl wrote: Øyvind Harboe pisze: Does anyone have a bunch of stuff that will be completed in the near future? How about that new LPC2xxx cfg files layout? With a bit of investigation the reset init should be working, or that can be left for future, as now this script is not fully functional either... When it's ready it should be committed, but I think this is one thing that either is ready by the time we cut 0.3 or not, we don't push out 0.3 for these changes. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
Øyvind Harboe pisze: When it's ready it should be committed, but I think this is one thing that either is ready by the time we cut 0.3 or not, we don't push out 0.3 for these changes. For me, the main cfg files layout is ready, I can make a patch even today. I'm just waiting for the opinions and a go sign. The reset-init script IMHO is a separate issue, which should be investigated further. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Tue, Sep 22, 2009 at 12:03 AM, David Brownell davi...@pacbell.net wrote: On Monday 21 September 2009, Rolf Meeser wrote: I've added a call to jtag_add_tlr(), and that solved it for me. All relevant EmbeddedICE registers are now reprogrammed. Did you try for example just adding a bunch of TCK cycles, via runtest? Or maybe just reading a register? (There's code elsewhere which uses register reads to work around things not getting set as expected.) We have too many add_tlr() calls already, and on systems with an ICEpick they will take the ARMs out of the scan chain. It's bad enough that happens four (!) times during a reset -- I want to get rid of most of them -- but let's not add them elsewhere except possibly as variant-specific behaviors. Could he be repairing a bug in the driver where the driver does not track the JTAG state correctly after a srst that pulls trst? -- Øyvind Harboe ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 anyone?
On Wednesday 16 September 2009, Øyvind Harboe wrote: Should we cut 0.3 soon? Not yet Any significant work that could be completed in the near future? I've got a bunch of patches; the new TAP-reset event isn't quite right etc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
