OpenOCD, JTAG, ARM

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.

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

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.

Hello,

Tauno Voipio writes: [...]

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

Regards hmw

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

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.

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

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

Cool. I'm happy to have guessed wrong.

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

me too ;). Thanks for the help anyways.

Now it would be interesting to know how that happened.

Regards hmw

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.

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.

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.

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

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.

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

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

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?

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.