Thanks... I'll look again at the '2106. Long ago, I looked and didn't see such a sense-bit.
--- In l..., Mike Harrison wrote:
>
> On Thu, 24 May 2012 03:22:33 -0000, you wrote:
>
> >A wish I have for JTAG, flash breakpoints, etc., is maybe an NXP unique issue... there's no way I can find to disable or otherwise keep control of the CPU/Core, with JTAG plugged in, when the watchdog timer expires. It just blows-up the debugger and JTAG.
> >
> >I'd wish that when JTAG is plugged in/active, the watchdog could be disabled as an option. Of course, there comes a time when you need to test the watchdog interrupt, but I tend to just let it reset the CPU.
> >
> >My code is so perfect that the watchdog can never fire.
>
> On some of the NXP parts, e.g. LPC2136 using PINSEL2, it is possible for software to detect when
> JTAG is being used, so the code can decide to not enable the watchdog at startup.
>

Start a New Thread

Thought I better document my Segger (IAR) J-Link problem properly...

Looks like the problem was an intermittent J-Link (yellow) JTAG box. We bought a (another) new one and it hasn't failed yet. No nasty 10 second interval "target is running" messages when USB cable is unplugged.

Not sure if my being banned on the Segger site will have any impact on my being able to get service in the future or not. We have a lot of these yellow and black JTAG programmers and debuggers here.

Thanks,
boB
--- In l..., "boB G" wrote:
>
>
>
> Hey !! Just in case anybody else sees this problem...
>
> I use IAR EWARM version 5.40 but also have 5.50.
> I use 5.40 because 5.50 didn't used to compile or link properly
> and I couldn't go through the pain of verifying our entire
> software changes with 5.50 after getting it to compile... SO...
> I just had another J-Link problem not being able to program.
> Re-installing the Segger drivers and re-booting did not help this time. SO I went to the bin directories of both versions and noticed that the file, jtag_usb.dll had a different date. I then backed up the old V5.40 one and copied over it with the V5.50 version.
>
> It worked !! It programmed again !
>
> Not sure how long this will work for, but it worked once at least.
>
> Whew !!
>
> boB
>
>
> PS. I usually use the Flash Loader in the Download options. Not sure if this jtag_usb.dll file is used for both FLdr and non-flash loader versions.
>
> PPS. Can I have my hair back now ???
>
>
> --- In l..., "boB G" wrote:
> >
> >
> > I have an Olimex OpenOCD JTAG programmer but haven't got it to quite work correctly yet with IAR. It does at least appear to program the flash. Well, at least it appears to screw it up and overwrite what was in there so it's doing something. Hopefully will get there...
> >
> >
> > My IAR J-Link has been working for over 3 years on this laptop and
> > lately it stops working and I have to re-install the drives and re-boot the computer after Control-Alt-Deleting to stop the errors from continuing for many minutes on end... All of my hair has been pulled out now...
> >
> > I suspect drivers or USB or something but there is evidently nobody anywhere that understands windows and USB drivers that can even give a clue. How the heck did this stuff get working in the first place ??
> >
> >
> > BTW, Anybody know J-Link reset number 9 might be ??
> >
> > (from the IAR J-Link log)
> > "Hardware reset with strategy 9 was performed"
> >
> >
> > boB
> >
> >
> > --- In l..., "stevec" wrote:
> > >
> > > J-link... guess I've been lucky? WIndows 7, windows XP, ARM7, never had any issues. The IAR debugger with flash breakpoints is great. If someone took away my flash breakpoints tool, I'd go after them with an axe!
> > >
> > > I wonder if this new IAR JTAG pod is made by Segger as was J-Link?
> > >
> > >
> > > --- In l..., "Paul Curtis" wrote:
> > > >
> > > > > > I actually would provide a different slant on this. The problem we
> > > > > > have with supporting 3P JTAG adapters is that they all have their
> > > > > > wrinkles, J-Link included (pre/post bits swapped between different DLL
> > > > > > versions, for instance). Offering a complete, known-working solution
> > > > > > from software through to debug adapter means you can control what
> > > > > > happens in your software end to end and nobody side-steps the issue.
> > > > > >
> > > > > Yes Paul, the better thing should be an universal adapter or an universal
> > > > > "standard" for the adapter implementation leaving the suppliers to do
> > > > > their best in other fields as speed, number of mcu supported, size and so
> > > > > on.
> > > >
> > > > For ARM, RDI is an open standard. I'm not sure how much it's used any more.
> > > > However, it's much harder to test n dev environments x m adapters than 1 dev
> > > > environment x 1 adapter. You can see the advantages...
> > > >
> > > > --
> > > > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > > > SolderCore running Defender... http://www.vimeo.com/25709426
> > > >
> > >
>

Start a New Thread