OpenOCD, JTAG, ARM

Hello,

I have this ARM eval board from IAR/Olimex. Suddenly (what ever that means) it stopped working. I can't connect anymore:

~> openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f ~/iar_lpc4088.cfg Open On-Chip Debugger 0.8.0-rc1 (2014-04-13-09:11) Licensed under GNU GPL v2 For bug reports, read

formatting link
Info : only one transport option; autoselect 'jtag' adapter speed: 10 kHz adapter_nsrst_delay: 200 jtag_ntrst_delay: 200 cortex_m reset_config sysresetreq cortex_m reset_config sysresetreq Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM Lite V8 compiled Nov 19 2010 15:25:05 Info : J-Link caps 0xb9ff7bbf Info : J-Link hw version 80000 Info : J-Link hw type J-Link Info : J-Link max mem block 8496 Info : J-Link configuration Info : USB-Address: 0xff Info : Kickstart power on JTAG-pin 19: 0xffffff01 Info : Vref = 3.332 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : clock speed 10 kHz Info : TAP lpc4088.cpu does not have IDCODE Warn : JTAG tap: lpc4088.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0) Error: JTAG tap: lpc4088.cpu expected 1 of 1: 0x410fc241 (mfg: 0x120, part: 0x10fc, ver: 0x4) Warn : Unexpected idcode after end of chain: 1 0xfffffff8 Error: double-check your JTAG setup (interface, speed, missing TAPs, ...) Error: Trying to use configured scan chain anyway... Error: lpc4088.cpu: IR capture error; saw 0x00 not 0x01 Warn : Bypassing JTAG setup events due to errors Warn : Invalid ACK 0x7 in JTAG-DP transaction

Any hints?

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle
Loading thread data ...

Only one, and I hope it's not right. Have you, by chance, changed the function of any port pins on the processor? I can's speak for your particular parts, but all the parts I've used have the "nifty" feature that if you change the function of a JTAG pin away from JTAG, then you're looking at an opportunity to learn surface-mount soldering skills, because the only cure that I know of is to replace the processor.

All my ARM software designs have a GPIO pin, on a port that's not used by JTAG (if possible), which, when grounded, goes into a tight little loop. BEFORE any other port-messing goes on. I put it in my startup code, I'm so paranoid.

It sounds stupid -- but it's saved my ass numerous times.

--
www.wescottdesign.com
Reply to
Tim Wescott

Hello,

Tim Wescott writes: [...]

after thinking about the problem for a while I came to the same conclusion. I'm not sure how this happened, but that's the only thing that could have happened. Well, maybe there is a little chance before my soldering skills come in. The board has a second JTAG port. With a little bit of luck that is still functional. But I need to order an adaptor before I can test that. And then there is the ISCP capability over the RS232 port. If that all doesn't work...

... I have at least learned something and a board equivalent of 200 bucks goes into the display case.

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

In the Atmel Cortexes, there are inputs for full chip erase. It has rescued me after painting myself in the corner, out of JTAG access.

At least the Atmel chips are not happy to talk with JTAG, if they do not have processor clock in. My guess is that this applies to other Cortex-M4 chips, too. It is against the JTAG standard, but I suspect that ARM needs the processor clock for the JTAG state machine. The TCK clock should be enough, but it is not.

--

-TV
Reply to
Tauno Voipio

Hello,

Tauno Voipio writes: [...]

that would help. I skimmed over the documentation earlier this day, but found nothing. More investigation is needed ;).

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

Hello,

Tauno Voipio writes: [...]

pulling down the ISP enable signal while booting should help for LCP17xx devices. Maybe I'll try and see what happens if I do this with my LPC4088.

Regards Gyro

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

First - does this happen all the time now even from a power on reset? At least on the LPC1769 system reset and jtag reset will not always fix a jtag comms issue. I have to power off the chip.

Hold P2[10] low during reset. This may at least get you to the point where the ISP can talk via the serial port. If one of the CRP modes has been set then you may be toast. Those can disable ISP. Look at Table 3 on page 35 of the data sheet and the section on the ISP.

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

Hello,

good news, the I can connect again ;). Thanks to Tauno for pushing me in the right direction. 1kOhm from ISP enable to ground let me connect via JTAG and erase the flash.

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

Hello,

Joe Chisolm writes: [...]

I powered off the device, didn't help. But pulling ISP enable down did the trick, JTAG works again ;).

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

Cool. I'm happy to have guessed wrong.

(That's one of the benefits of being a pessimist).

--
www.wescottdesign.com
Reply to
Tim Wescott

me too ;). Thanks for the help anyways.

Now it would be interesting to know how that happened.

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

I'm not familiar with the chip in question, but if enabling the ISP makes JTAG work, then it sounds like something in your software is making JTAG _not_ work.

I'd do what I mentioned before -- look at the port setup, and make sure that your code isn't stomping on the JTAG pins.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I think that has to be a flaw in the chip. I believe the spec for JTAG is such that JTAG can take over the chip at any time. There should be no need for asserting an ISP pin.

--

Rick
Reply to
rickman

It seems to be a common ARM problem. At least in ARM7TDMI and Cortex-M, the JTAG interface quits, if the processor is left without clock. The newer processors have complicated programmable clock generating chains, which are easy to mis-program (been there, bricked many).

My guess is that all the logic in the synthesized core needs the main clock to run at all. And - yes, it is against the JTAG standard.

--

-TV
Reply to
Tauno Voipio

plenty of processors where you can turn of the jtag and use the pins for something else, at that point the chip no longer has jtag so even if jtag had spec that said it should work at all times which I very much doubt it doesn't matter

-Lasse

Reply to
langwadt

That's actually what led me to assigning a "debrick" pin -- my very first experience with an ARM Cortex part had me ordering replacement chips for an eval board after I flubbed the PLL setup and bricked it.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Hello,

Tim Wescott writes: [...]

my code at that time was a nearly empty main function, no registers or memory locations had been accessed from the C code. Since I'm new to ARM I tried some experiments to find out how the tool chain works. Maybe I forgot to erase the flash, flashed the binary to the 'wrong' place and some garbage in the flash was interpreted at code?

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

Hello,

snipped-for-privacy@fonz.dk writes: [...]

I haven't studied the spec in deep yet, but IIRC some JTAG pins are reused only for SWD. I think they can't be used as GPIOs on this controller.

Perhaps the problem was somehow clock related, as Tauno suggested. It's hard to speculate now. Maybe I f* up the board again in my experiments. Then, with all the possibilities what can go wrong in mind, I will have a closer look at the problem.

Regards hmw

--
biff4emacsen - A biff-like tool for (X)Emacs 
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html 
 Click to see the full signature
Reply to
Michael Welle

Correct me if I am wrong,. but not all ARM ... setups are this way, to my observation.

So what do you gain for the extra risk of bricking the thing? Seems unnecessarily risky. And I presume that the "debrick" pin just grounds something on the chip?

--
Les Cargill
Reply to
Les Cargill

The clock generator needs to be set up from the initial RC limp oscillator started at reset. At least the brickings I have done were difficulties in setting the clock generator registers so that the thing has a legal clock under the time of setting up. There are fascinating implications in writing the registers, and all are not written out clearly in the data sheets.

The debrick pin in Atmel's SAMs needs to be pulled up for some hundreds of milliseconds at reset, to erase all the internal flash. It is an I/O pin, but it is sensed before any I/O setup at reset.

--

-TV
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.