I have an Olimex LPC2106 header board. I was not having any luck
getting this to communicate with an LPT port debugger, so I did a
few tests.
According to the LPC2106 datasheet (Section 18 - EmbeddedICE logic),
both the DBGSEL and RTCK pins must be held high on reset to enter
debugging mode. However, the document with the header board from
Olimex says that DBGSEL should be held low during power up to enable
debug mode, and it doesn't mention RTCK at all. I tried all 4
combinations of logic on these two pins, using both reset and
removing and re-applying power. Regardless, I always found that TDO
is floating. If I'm understanding correctly, it should be either
high or low at all times in debug mode since it is the JTAG data
output.
To eliminate possible parallel port issues, I used another
microcontroller to attempt to communicate with the JTAG port for
testing purposes. As expected, I found that TDO remains floating
throughout all attempts at communication. Next I tried configuring
the secondary JTAG pins via a short program. When I do this, I find
that TDO (using the secondary port) assumes a strong high or low
state, which changes during communication. Looking at a JTAG state
diagram and doing a bit of bit twiddling, I found I was able to get
into Shift-DR mode on the JTAG port. I was able to read the device
ID (I got 0x4F1F0F0F). However, attempts to write the IR did not
work. Regardless what I wrote to IR I would get the device ID back
when I read data in from DR.
I know my circuit is good, given that I can communicate manually via
the secondary JTAG port (in a limited fashion, which may be due my
incomplete understanding of the JTAG protocol). Why won't the
primary JTAG port work at all?
I remember once reading that some people had problems getting the
primary JTAG port to work with a different LPC2* chip (I don't
remember which chip but it was not the 2106). The Olimex board has
a 14.7456MHz crystal (which I can't change). Could that be part of
my problem?
Incidentally, I noted that a sample "LED flash" program continued
running happily throughout all my tests (even where I was
communicating actively with the secondary JTAG port). Is this
normal?
Thanks for any help.
Frank
LPC2106 Refuses to Enter Primary JTAG Debug Mode
Started by ●January 2, 2006
Reply by ●January 2, 20062006-01-02
I'm confused by what you have said but here's what I think I know:
RTCK is pulled high on the board. No problem.
To enter and use JTAG debug, DBGSEL must be pulled high. It is
normally held low by a pull down resistor. Install the jumper to
use JTAG. The BSL jumper doesn't matter during JTAG operation.
This is the way it is described in James Lynch's tutorial on page
7. And, other than issues with OCDRemote, it worked for me when I
first tried using JTAG. Do to a limited number of pins, I am not
currently using it. Richard
--- In lpc2000@lpc2..., "frank_kienast" <fkienast@v...>
wrote:
>
> I have an Olimex LPC2106 header board. I was not having any luck
> getting this to communicate with an LPT port debugger, so I did a
> few tests.
>
> According to the LPC2106 datasheet (Section 18 - EmbeddedICE
logic),
> both the DBGSEL and RTCK pins must be held high on reset to enter
> debugging mode. However, the document with the header board from
> Olimex says that DBGSEL should be held low during power up to
enable
> debug mode, and it doesn't mention RTCK at all. I tried all 4
> combinations of logic on these two pins, using both reset and
> removing and re-applying power. Regardless, I always found that
TDO
> is floating. If I'm understanding correctly, it should be either
> high or low at all times in debug mode since it is the JTAG data
> output.
>
> To eliminate possible parallel port issues, I used another
> microcontroller to attempt to communicate with the JTAG port for
> testing purposes. As expected, I found that TDO remains floating
> throughout all attempts at communication. Next I tried
configuring
> the secondary JTAG pins via a short program. When I do this, I
find
> that TDO (using the secondary port) assumes a strong high or low
> state, which changes during communication. Looking at a JTAG
state
> diagram and doing a bit of bit twiddling, I found I was able to
get
> into Shift-DR mode on the JTAG port. I was able to read the
device
> ID (I got 0x4F1F0F0F). However, attempts to write the IR did not
> work. Regardless what I wrote to IR I would get the device ID
back
> when I read data in from DR.
>
> I know my circuit is good, given that I can communicate manually
via
> the secondary JTAG port (in a limited fashion, which may be due my
> incomplete understanding of the JTAG protocol). Why won't the
> primary JTAG port work at all?
>
> I remember once reading that some people had problems getting the
> primary JTAG port to work with a different LPC2* chip (I don't
> remember which chip but it was not the 2106). The Olimex board
has
> a 14.7456MHz crystal (which I can't change). Could that be part
of
> my problem?
>
> Incidentally, I noted that a sample "LED flash" program continued
> running happily throughout all my tests (even where I was
> communicating actively with the secondary JTAG port). Is this
> normal?
>
> Thanks for any help.
>
> Frank
>
Reply by ●January 3, 20062006-01-03
Thanks for the reply. I am in fact pulling both DBGSEL and RTCK
high. I tried all 4 possible combinations of logic levels on these
two pins and none of them cause TDO to do anything other than float
upon reset or powerup.
Frank
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
>
> I'm confused by what you have said but here's what I think I
know:
> RTCK is pulled high on the board. No problem.
>
> To enter and use JTAG debug, DBGSEL must be pulled high. It is
> normally held low by a pull down resistor. Install the jumper to
> use JTAG. The BSL jumper doesn't matter during JTAG operation.
>
> This is the way it is described in James Lynch's tutorial on page
> 7. And, other than issues with OCDRemote, it worked for me when I
> first tried using JTAG. Do to a limited number of pins, I am not
> currently using it. > Richard
>
> --- In lpc2000@lpc2..., "frank_kienast" <fkienast@v...>
> wrote:
> >
> > I have an Olimex LPC2106 header board. I was not having any
luck
> > getting this to communicate with an LPT port debugger, so I did
a
> > few tests.
> >
> > According to the LPC2106 datasheet (Section 18 - EmbeddedICE
> logic),
> > both the DBGSEL and RTCK pins must be held high on reset to
enter
> > debugging mode. However, the document with the header board
from
> > Olimex says that DBGSEL should be held low during power up to
> enable
> > debug mode, and it doesn't mention RTCK at all. I tried all 4
> > combinations of logic on these two pins, using both reset and
> > removing and re-applying power. Regardless, I always found that
> TDO
> > is floating. If I'm understanding correctly, it should be
either
> > high or low at all times in debug mode since it is the JTAG data
> > output.
> >
> > To eliminate possible parallel port issues, I used another
> > microcontroller to attempt to communicate with the JTAG port for
> > testing purposes. As expected, I found that TDO remains
floating
> > throughout all attempts at communication. Next I tried
> configuring
> > the secondary JTAG pins via a short program. When I do this, I
> find
> > that TDO (using the secondary port) assumes a strong high or low
> > state, which changes during communication. Looking at a JTAG
> state
> > diagram and doing a bit of bit twiddling, I found I was able to
> get
> > into Shift-DR mode on the JTAG port. I was able to read the
> device
> > ID (I got 0x4F1F0F0F). However, attempts to write the IR did
not
> > work. Regardless what I wrote to IR I would get the device ID
> back
> > when I read data in from DR.
> >
> > I know my circuit is good, given that I can communicate manually
> via
> > the secondary JTAG port (in a limited fashion, which may be due
my
> > incomplete understanding of the JTAG protocol). Why won't the
> > primary JTAG port work at all?
> >
> > I remember once reading that some people had problems getting
the
> > primary JTAG port to work with a different LPC2* chip (I don't
> > remember which chip but it was not the 2106). The Olimex board
> has
> > a 14.7456MHz crystal (which I can't change). Could that be part
> of
> > my problem?
> >
> > Incidentally, I noted that a sample "LED flash" program
continued
> > running happily throughout all my tests (even where I was
> > communicating actively with the secondary JTAG port). Is this
> > normal?
> >
> > Thanks for any help.
> >
> > Frank
> >
>
high. I tried all 4 possible combinations of logic levels on these
two pins and none of them cause TDO to do anything other than float
upon reset or powerup.
Frank
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote:
>
>
> I'm confused by what you have said but here's what I think I
know:
> RTCK is pulled high on the board. No problem.
>
> To enter and use JTAG debug, DBGSEL must be pulled high. It is
> normally held low by a pull down resistor. Install the jumper to
> use JTAG. The BSL jumper doesn't matter during JTAG operation.
>
> This is the way it is described in James Lynch's tutorial on page
> 7. And, other than issues with OCDRemote, it worked for me when I
> first tried using JTAG. Do to a limited number of pins, I am not
> currently using it. > Richard
>
> --- In lpc2000@lpc2..., "frank_kienast" <fkienast@v...>
> wrote:
> >
> > I have an Olimex LPC2106 header board. I was not having any
luck
> > getting this to communicate with an LPT port debugger, so I did
a
> > few tests.
> >
> > According to the LPC2106 datasheet (Section 18 - EmbeddedICE
> logic),
> > both the DBGSEL and RTCK pins must be held high on reset to
enter
> > debugging mode. However, the document with the header board
from
> > Olimex says that DBGSEL should be held low during power up to
> enable
> > debug mode, and it doesn't mention RTCK at all. I tried all 4
> > combinations of logic on these two pins, using both reset and
> > removing and re-applying power. Regardless, I always found that
> TDO
> > is floating. If I'm understanding correctly, it should be
either
> > high or low at all times in debug mode since it is the JTAG data
> > output.
> >
> > To eliminate possible parallel port issues, I used another
> > microcontroller to attempt to communicate with the JTAG port for
> > testing purposes. As expected, I found that TDO remains
floating
> > throughout all attempts at communication. Next I tried
> configuring
> > the secondary JTAG pins via a short program. When I do this, I
> find
> > that TDO (using the secondary port) assumes a strong high or low
> > state, which changes during communication. Looking at a JTAG
> state
> > diagram and doing a bit of bit twiddling, I found I was able to
> get
> > into Shift-DR mode on the JTAG port. I was able to read the
> device
> > ID (I got 0x4F1F0F0F). However, attempts to write the IR did
not
> > work. Regardless what I wrote to IR I would get the device ID
> back
> > when I read data in from DR.
> >
> > I know my circuit is good, given that I can communicate manually
> via
> > the secondary JTAG port (in a limited fashion, which may be due
my
> > incomplete understanding of the JTAG protocol). Why won't the
> > primary JTAG port work at all?
> >
> > I remember once reading that some people had problems getting
the
> > primary JTAG port to work with a different LPC2* chip (I don't
> > remember which chip but it was not the 2106). The Olimex board
> has
> > a 14.7456MHz crystal (which I can't change). Could that be part
> of
> > my problem?
> >
> > Incidentally, I noted that a sample "LED flash" program
continued
> > running happily throughout all my tests (even where I was
> > communicating actively with the secondary JTAG port). Is this
> > normal?
> >
> > Thanks for any help.
> >
> > Frank
> >
>
Reply by ●January 3, 20062006-01-03
Hello all!,
I am starting a project that is basically a CAN bus router/gateway. I
was looking at ARM MCUs that have 3-4 CAN channels on them. Here is the
list/questions right now:
Freescale MAC71xx MCUs - 4 CAN bus channels - Anyone used this part
before?? Any pitfalls????
Philips LPC21xx MCUs - 4 CAN bus channels - Has Philips fixed the
CAN issues explained in the errata on the current mask sets????
TI TMS470xxx MCUs - 3 CAN bus channels - Anyone used this part
before?? Any pitfalls????
I guess I could go with multiple single/dual channel parts and communicate
to a "Master" MCU for arbitration/routing of the CAN bus messages.
Thanks,
Brian K. Mohlman
Project Engineer (Electrical)
Advanced Concepts Design Engineering
JLG Industries Inc.
1 JLG Drive
McConnellsburg, PA 17233
Ph. (717) 485-6495
mailto:bkmohlman@bkmo...
http://www.jlg.com
http://www.gradall.com
***********************************************************************
The information contained in this transmission is confidential. It is
intended solely for the use of the individual(s) or organization(s) to
whom it is addressed. Any disclosure, copying or further distribution
is not permitted unless such privilege is explicitly granted in writing
by JLG Industries, Inc.
Further, JLG Industries, Inc. is not responsible for the proper and
complete transmission of the substance of this communication nor for
any delay in its receipt.
Reply by ●January 3, 20062006-01-03
Hi Brian,
> Freescale MAC71xx MCUs - 4 CAN bus channels - Anyone used this part
> before?? Any pitfalls????
My response from Freescale a while back on some nice feature CAN enabled
MAC71xx parts was that they are only available to tier 1 automotive
suppliers. Perhaps they need a tight loop on silicon due to bugs?
> Philips LPC21xx MCUs - 4 CAN bus channels - Has Philips fixed the
> CAN issues explained in the errata on the current mask sets????
I've seen no update as to when new silicon revision will be shipping.
> I guess I could go with multiple single/dual channel parts and communicate
> to a "Master" MCU for arbitration/routing of the CAN bus messages.
There is also the ST STR710 series, available in TQFP and LFBGA.
http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str710 I'm curious to what your selection will be. Joel
> Freescale MAC71xx MCUs - 4 CAN bus channels - Anyone used this part
> before?? Any pitfalls????
My response from Freescale a while back on some nice feature CAN enabled
MAC71xx parts was that they are only available to tier 1 automotive
suppliers. Perhaps they need a tight loop on silicon due to bugs?
> Philips LPC21xx MCUs - 4 CAN bus channels - Has Philips fixed the
> CAN issues explained in the errata on the current mask sets????
I've seen no update as to when new silicon revision will be shipping.
> I guess I could go with multiple single/dual channel parts and communicate
> to a "Master" MCU for arbitration/routing of the CAN bus messages.
There is also the ST STR710 series, available in TQFP and LFBGA.
http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str710 I'm curious to what your selection will be. Joel
Reply by ●January 3, 20062006-01-03
Just a note that AT91SAM7A2 has 4 CAN ports.
http://www.atmel.com/dyn/products/product_card.asp?part_id397
-- Doug
http://www.atmel.com/dyn/products/product_card.asp?part_id397
-- Doug
Reply by ●January 3, 20062006-01-03
> Just a note that AT91SAM7A2 has 4 CAN ports.
> http://www.atmel.com/dyn/products/product_card.asp?part_id397
There's no internal Flash on the AT91SAM7A2.
I've spec'd the AT91SAM7A3 on an upcoming project. I hope it's as nice as
it looks!
Joel
> http://www.atmel.com/dyn/products/product_card.asp?part_id397
There's no internal Flash on the AT91SAM7A2.
I've spec'd the AT91SAM7A3 on an upcoming project. I hope it's as nice as
it looks!
Joel
Reply by ●January 5, 20062006-01-05
> Regardless, I always found that TDO
> is floating. If I'm understanding correctly, it should be either
> high or low at all times in debug mode since it is the JTAG data
> output.
Many times I've wished to stumble onto a PDF of the 1149.1 JTAG spec....
(hint, hint).... But here's one of the better tutorials with quite a
bit of info:
http://www.asset-intertech.com/pdfs/boundaryscan_tutorial.pdf
Turn to page 32, where they claim that TDO defaults to Hi-Z except
"during a shift operation". If that's true, you might have to control
TMS and clock TCK to travel though several states to get into Shift-DR
or Shift-IR. While you're at it, reading out the IDCODE register
wouldn't be too much more work, and that'd tell you for sure. Well,
based on the tutorial and some hands-on experiementation (or fumbling
around) with JTAG without the official spec.
Of course, if anyone happens to know of a copy of 1149.1 just laying
around for free on some server..... -Paul
Reply by ●January 5, 20062006-01-05
Respected Sir ,
I am working on LPC-2106 based project. (software). Actually I want to generate square wave ( 50%) duty cycle on one port pin of lpc2106 using timer0. And also I want to see the this waveform on logic analyser window. I am using Keiluvision2 free evaluated version copy. So Can I see the waveform using logic analyser in the same.
Pl. guide me because I am using first time LPC2106 AND KEIL also.
Can you give some idea about the source code for the same.
Thanks and Best Regards
Pramod Paul Stoffregen <Paul@Paul...> wrote:
> Regardless, I always found that TDO
> is floating. If I'm understanding correctly, it should be either
> high or low at all times in debug mode since it is the JTAG data
> output.
Many times I've wished to stumble onto a PDF of the 1149.1 JTAG spec....
(hint, hint).... But here's one of the better tutorials with quite a
bit of info:
http://www.asset-intertech.com/pdfs/boundaryscan_tutorial.pdf
Turn to page 32, where they claim that TDO defaults to Hi-Z except
"during a shift operation". If that's true, you might have to control
TMS and clock TCK to travel though several states to get into Shift-DR
or Shift-IR. While you're at it, reading out the IDCODE register
wouldn't be too much more work, and that'd tell you for sure. Well,
based on the tutorial and some hands-on experiementation (or fumbling
around) with JTAG without the official spec.
Of course, if anyone happens to know of a copy of 1149.1 just laying
around for free on some server..... -Paul ---------------------------------
YAHOO! GROUPS LINKS --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com
I am working on LPC-2106 based project. (software). Actually I want to generate square wave ( 50%) duty cycle on one port pin of lpc2106 using timer0. And also I want to see the this waveform on logic analyser window. I am using Keiluvision2 free evaluated version copy. So Can I see the waveform using logic analyser in the same.
Pl. guide me because I am using first time LPC2106 AND KEIL also.
Can you give some idea about the source code for the same.
Thanks and Best Regards
Pramod Paul Stoffregen <Paul@Paul...> wrote:
> Regardless, I always found that TDO
> is floating. If I'm understanding correctly, it should be either
> high or low at all times in debug mode since it is the JTAG data
> output.
Many times I've wished to stumble onto a PDF of the 1149.1 JTAG spec....
(hint, hint).... But here's one of the better tutorials with quite a
bit of info:
http://www.asset-intertech.com/pdfs/boundaryscan_tutorial.pdf
Turn to page 32, where they claim that TDO defaults to Hi-Z except
"during a shift operation". If that's true, you might have to control
TMS and clock TCK to travel though several states to get into Shift-DR
or Shift-IR. While you're at it, reading out the IDCODE register
wouldn't be too much more work, and that'd tell you for sure. Well,
based on the tutorial and some hands-on experiementation (or fumbling
around) with JTAG without the official spec.
Of course, if anyone happens to know of a copy of 1149.1 just laying
around for free on some server..... -Paul ---------------------------------
YAHOO! GROUPS LINKS --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com
Reply by ●January 5, 20062006-01-05
Hi,
> I am working on LPC-2106 based project. (software).
> Actually I want to generate square wave ( 50%) duty cycle on
> one port pin of lpc2106 using timer0. And also I want to see
> the this waveform on logic analyser window. I am using
> Keiluvision2 free evaluated version copy. So Can I see the
> waveform using logic analyser in the same.
>
> Pl. guide me because I am using first time LPC2106 AND KEIL also.
>
> Can you give some idea about the source code for the same.
>
> Thanks and Best Regards
>
> Pramod
Ask your tutor. He should be able to help you out here.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> I am working on LPC-2106 based project. (software).
> Actually I want to generate square wave ( 50%) duty cycle on
> one port pin of lpc2106 using timer0. And also I want to see
> the this waveform on logic analyser window. I am using
> Keiluvision2 free evaluated version copy. So Can I see the
> waveform using logic analyser in the same.
>
> Pl. guide me because I am using first time LPC2106 AND KEIL also.
>
> Can you give some idea about the source code for the same.
>
> Thanks and Best Regards
>
> Pramod
Ask your tutor. He should be able to help you out here.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
