OpenOCD, JTAG, ARM

[Michael Welle]

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
http://openocd.sourceforge.net/doc/doxygen/bugs.html
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

[Tim Wescott]

Post by Michael Welle
Hello,
I have this ARM eval board from IAR/Olimex. Suddenly (what ever that
~> 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
http://openocd.sourceforge.net/doc/doxygen/bugs.html
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 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
USB-Address: 0xff Info : Kickstart power on JTAG-pin 19: 0xffffff01 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)
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?

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.

[Michael Welle]

Hello,

Tim Wescott <***@seemywebsite.com> writes:
[...]

Post by Tim Wescott
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.

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...

Post by Tim Wescott
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.

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

Regards
hmw

[Tauno Voipio]

Post by Michael Welle
Hello,
[...]

Post by Tim Wescott
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.

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...

Post by Tim Wescott
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.

... 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.

[Michael Welle]

Hello,

Tauno Voipio <***@notused.fi.invalid> writes:
[...]

Post by Tauno Voipio
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.

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

Regards
hmw

[Michael Welle]

Hello,

Tauno Voipio <***@notused.fi.invalid> writes:
[...]

Post by Tauno Voipio
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.

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

[Michael Welle]

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

[Tim Wescott]

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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

[Michael Welle]

Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

me too ;). Thanks for the help anyways.

Now it would be interesting to know how that happened.

Regards
hmw

[Tim Wescott]

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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.

[rickman]

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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.

[Tauno Voipio]

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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.

[Tim Wescott]

Post by Tauno Voipio

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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.

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.

[Les Cargill]

Post by Tim Wescott

Post by Tauno Voipio

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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.

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.

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?

[Tauno Voipio]

Post by Les Cargill

Post by Tim Wescott

Post by Tauno Voipio
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.

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.

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.

[Les Cargill]

Post by Tauno Voipio

Post by Les Cargill

Post by Tim Wescott

Post by Tauno Voipio
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.

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.

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.

Yeah, I got all that but I just wonder why they bothered with that
design to start with?

The ARM chips I have dealt with, all you lost when messing up any PLL
setup was the DRAM interface.

Post by Tauno Voipio
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.

Ah, thanks.

[l***@fonz.dk]

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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.

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

[Michael Welle]

Hello,

***@fonz.dk writes:
[...]

Post by l***@fonz.dk
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

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.

Post by l***@fonz.dk
had spec that said it should work at all times which I very much doubt
it doesn't matter

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

[Tim Wescott]

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior is
shared by all the ARM Cortex parts that I've used, both from Luminary/TI
and from ST.

[Tauno Voipio]

Post by Tim Wescott

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior is
shared by all the ARM Cortex parts that I've used, both from Luminary/TI
and from ST.

As far as I know, the JTAG is a part of the core design coming as a
block from ARM to the sublicensees. The documentation is very careful
about the details, but my guess is that the whole core block is
synthetized synchronous logic, running on the core clock. There is
a hint about it, when it is said that one should not use the WFI
(wait for interrupt) instruction, if it is desired to debug with JTAG.

[Tim Wescott]

Post by Tauno Voipio

Post by Tim Wescott

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior is
shared by all the ARM Cortex parts that I've used, both from
Luminary/TI and from ST.

As far as I know, the JTAG is a part of the core design coming as a
block from ARM to the sublicensees. The documentation is very careful
about the details, but my guess is that the whole core block is
synthetized synchronous logic, running on the core clock. There is a
hint about it, when it is said that one should not use the WFI (wait for
interrupt) instruction, if it is desired to debug with JTAG.

I can't remember the wording, but I felt that the verbiage surrounding the
WFI instruction stuff was more than a hint.

And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM
had built something in so to detect activity on the JTAG port and flip a
bit -- it would be nice to sense the presense of JTAG and refrain from
using the WFI instruction.

[Tauno Voipio]

Post by Tim Wescott

Post by Tauno Voipio

Post by Tim Wescott

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior is
shared by all the ARM Cortex parts that I've used, both from
Luminary/TI and from ST.

As far as I know, the JTAG is a part of the core design coming as a
block from ARM to the sublicensees. The documentation is very careful
about the details, but my guess is that the whole core block is
synthetized synchronous logic, running on the core clock. There is a
hint about it, when it is said that one should not use the WFI (wait for
interrupt) instruction, if it is desired to debug with JTAG.

I can't remember the wording, but I felt that the verbiage surrounding the
WFI instruction stuff was more than a hint.
And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM
had built something in so to detect activity on the JTAG port and flip a
bit -- it would be nice to sense the presense of JTAG and refrain from
using the WFI instruction.

Or just pick the clock to the JTAG part ahead of the WFI gating.

The best would be to follow the schematics in the JTAG standard
and just clock that part from TCK alone.

[Tim Wescott]

Post by Tauno Voipio

Post by Tim Wescott

Post by Tauno Voipio

Post by Tim Wescott

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior is
shared by all the ARM Cortex parts that I've used, both from
Luminary/TI and from ST.

As far as I know, the JTAG is a part of the core design coming as a
block from ARM to the sublicensees. The documentation is very careful
about the details, but my guess is that the whole core block is
synthetized synchronous logic, running on the core clock. There is a
hint about it, when it is said that one should not use the WFI (wait
for interrupt) instruction, if it is desired to debug with JTAG.

I can't remember the wording, but I felt that the verbiage surrounding
the WFI instruction stuff was more than a hint.
And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM
had built something in so to detect activity on the JTAG port and flip
a bit -- it would be nice to sense the presense of JTAG and refrain
from using the WFI instruction.

Or just pick the clock to the JTAG part ahead of the WFI gating.
The best would be to follow the schematics in the JTAG standard and just
clock that part from TCK alone.

Well, I suppose if I'm wishing -- yes. But from TCK please -- WFI is
there to minimize power consumption, which is kinda hard if you have some
obligate clocked portion of the chip.

I'm thinking maybe I'll build something into the software to run for five
minutes or so without WFI, and then enable it if some bit somewhere isn't
set. That'll let JTAG come up in "human time".

[Joe Chisolm]

Post by Tim Wescott

Post by Tauno Voipio

Post by Tim Wescott

Post by Tauno Voipio

Post by Tim Wescott

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior
is shared by all the ARM Cortex parts that I've used, both from
Luminary/TI and from ST.

As far as I know, the JTAG is a part of the core design coming as a
block from ARM to the sublicensees. The documentation is very careful
about the details, but my guess is that the whole core block is
synthetized synchronous logic, running on the core clock. There is a
hint about it, when it is said that one should not use the WFI (wait
for interrupt) instruction, if it is desired to debug with JTAG.

I can't remember the wording, but I felt that the verbiage surrounding
the WFI instruction stuff was more than a hint.
And the WFI does, indeed, royally screw JTAG. I do kinda wish that
ARM had built something in so to detect activity on the JTAG port and
flip a bit -- it would be nice to sense the presense of JTAG and
refrain from using the WFI instruction.

Or just pick the clock to the JTAG part ahead of the WFI gating.
The best would be to follow the schematics in the JTAG standard and
just clock that part from TCK alone.

Well, I suppose if I'm wishing -- yes. But from TCK please -- WFI is
there to minimize power consumption, which is kinda hard if you have
some obligate clocked portion of the chip.
I'm thinking maybe I'll build something into the software to run for
five minutes or so without WFI, and then enable it if some bit somewhere
isn't set. That'll let JTAG come up in "human time".

At least on the 1768/69 the wfi shuts down *some* DMA transfers. This
caught me when I moved a buffer to the main memory block in my linker
script:

"The GPDMA may operate in Sleep mode to access AHB SRAMs and peripherals
with GPDMA support, but the GPDMA cannot access the flash memory or the
main SRAM, which are disabled in order to save power."

Also happens if you build a DMA chain where some of the transfer is
const text in flash.

You will be waiting on the DMA interrupt until your WDT goes off.

[l***@fonz.dk]

Post by Tauno Voipio

Post by Tim Wescott

Post by Tauno Voipio

Post by Tim Wescott

Post by rickman

Post by Tim Wescott

Post by Michael Welle
Hello,

Post by Tim Wescott

Post by Michael Welle
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

Cool. I'm happy to have guessed wrong.

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 may be a flaw, but if so it's an intentional one. The behavior is
shared by all the ARM Cortex parts that I've used, both from
Luminary/TI and from ST.

As far as I know, the JTAG is a part of the core design coming as a
block from ARM to the sublicensees. The documentation is very careful
about the details, but my guess is that the whole core block is
synthetized synchronous logic, running on the core clock. There is a
hint about it, when it is said that one should not use the WFI (wait for
interrupt) instruction, if it is desired to debug with JTAG.

I can't remember the wording, but I felt that the verbiage surrounding the
WFI instruction stuff was more than a hint.
And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM
had built something in so to detect activity on the JTAG port and flip a
bit -- it would be nice to sense the presense of JTAG and refrain from
using the WFI instruction.

Or just pick the clock to the JTAG part ahead of the WFI gating.
The best would be to follow the schematics in the JTAG standard
and just clock that part from TCK alone.

it is more complicated than that, (it's been 10+ year since I worked on ARM but..) all then boundary scan etc. works just fine, but everything that talk
to the CPU is sampled with cpu clk to avoid the async clock, that is also the reason for rclk which is just the tck sampled with clock

talking to the cpu is mostly handfeeding data and enabling a single clock cycle

-Lasse

[Michael Welle]

Hello,

Tim Wescott <***@myfooter.really> writes:
[...]

Post by Tim Wescott
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.

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

[Joe Chisolm]

Post by Michael Welle
Hello,
I have this ARM eval board from IAR/Olimex. Suddenly (what ever that
~> 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
http://openocd.sourceforge.net/doc/doxygen/bugs.html
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
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
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

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.

[Michael Welle]

Hello,

Joe Chisolm <***@earthlink.net> writes:
[...]

Post by Joe Chisolm
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.

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

Regards
hmw